Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 21 May 85 10:08:21 EST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
	id AA19795; Tue, 21 May 85 06:12:06 pdt
Received: by ucbdali.ARPA (4.24/4.46)
	id AA16444; Tue, 21 May 85 06:14:18 pdt
Date: Tue, 21 May 85 06:14:18 pdt
From: bh%ucbdali@Berkeley (Brian Harvey)
Message-Id: <8505211314.AA16444@ucbdali.ARPA>
To: info-gnu@mc, rms@mit-prep
Subject: Re:  File version numbers for GNU

One small problem with the end-with-period convention is that it makes
'.' and '..' ambiguous.  No doubt you can invent rules to disambiguate
for the computer, but it'll still be an easy thing for people to get
confused about.  Perhaps it would be better to use semicolon instead
even though that needs to be shell-escaped.  Or some hitherto-meaningless
character like equal sign.

I'd like a little more discussion on why you say "any punctuation character"
instead of picking one.  I think there is a lot to be said for having a
specific character (equal sign is growing on me as I type this) that lets
both people and computers know unambiguously that a version number is
intended.  There have been times when I've used numeric extensions with
specific meanings.  A recent example is that the TeX fonts for the Imagen
printer at SAIL have filenames like CMR10.392 where the 392 indicates the
magnification in some units or other.

Finally, I strongly urge that provision be made for people like me who
passionately despise version numbers and never want any of our files to
have version numbers.  For example, that "completed" bit per file doesn't
mean anything for a directory, so it could be recycled to mean "don't
create files with version numbers in this directory."  I don't want to have
to type periods at the end of every single word in every single command for
the rest of my life!

Oh, sorry, I take back "finally."  It should be noted that some existing
Unix software breaks when run under a version number system because it
uses the existence of a file as a flag for some purpose and gets confused
if there can be more than one.  The example I remember right now is uucp.
(Actually I guess I mean uucico.)  It has these files called STST.host
containing the status of the connection to that host.  During the course
of a connection, it overwrites (replaces) that file a few times, and then
finally deletes it.  In a version number system, that deletion doesn't
actually get rid of the file, but merely uncovers an earlier version.
Then the next attempt to talk with that host gets confused.  I experienced
this problem trying to make uucp work under Eunice, the Unix simulator for
VMS.  Now that you know about this particular case you can have uucico
do exact-match opens, but the point is that there are probably other programs
out there written for Unix that will fail in similar ways and need revision.
(Oh, I just reminded myself, if you rm a file does the latest version or the
earliest version disappear?  If there are levels of versions, is it the
earliest version in the latest superversion, or the earliest version in
the earliest superversion?)

Received: from MIT-PREP by MIT-MC via Chaosnet; 21 MAY 85  01:54:09 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA08586; Tue, 21 May 85 01:49:11 edt
Date: Tue, 21 May 85 01:49:11 edt
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: File version numbers for GNU

Here is my idea for version numbers in GNU.
I would like to hear any suggestions for improving it.
Also, if you see any specific procedure that people now typically use
or would want to use in which this scheme would cause trouble,
please describe it to me so I can investigate solutions.


At the lowest level, a version number is part of the file name.
A version number suffix consists of a punctuation character
followed by digits.  If a file name ends in a version number
suffix then it has a version number.  If what is left when
that suffix is removed also ends in a version number suffix,
then the file has two version numbers; for example,
`emacs-15.34'.  A file name can contain any number of version numbers.

Version number suffixes are understood specially by the
`open' system call.  Here are the details of how a name is opened:

1) if O_NOVERSION is set, look for an exact match against the
 specified NAME.  If no match, fail or create a file named exactly NAME.

2) Otherwise, if NAME ends in a period, remove the period
 to get REALNAME.  Look for an exact match for REALNAME;
 if none, fail or create a file named exactly REALNAME.

[Note that this allows you to specify any name whatever, for exact use,
 by appending a period to it.]

3) Otherwise, look for an exact match against NAME, and
 use that file if a match is found.

4) Otherwise, look for NAME followed by version number suffixes.
 if reading,
  choose the `largest' sequence of suffixes whose file has its `completed'
  flag set, and open that file.
 if writing,
  choose the `largest' sequence of suffixes,
  modify it by incrementing the last suffix in the sequence,
  and use that to get the name to open.

[The `completed' flag of a file will be set when the
 file is closed normally.  If a program dies writing
 a file, or the system crashes, the `completed' flag
 will never be set (though there may be a system call to set it).
 This way, files not completely written are normally invisible
 when version numbers are in use, but they can be opened
 using any tool by specifying the exact file name with a period.]
 
5) If nothing is found with version number suffixes,
 fail or create NAME.1

Globbing is affected by version numbers, because two kinds of
globbing are needed: with versions, and version-free.

Here is the design I have thought of:

If a globbing pattern ends in a period, then it is matched
against a list of all filenames in the directory, including
their version numbers if any, and each with a period tacked on.

If a globbing pattern does not end in a period, then it is matched
against a list of all filenames in the directory, each with
all version numbers removed (and resulting duplicates deleted).

Thus, `*.c.*.' might expand into
 `bar.c.34.8. bar.c.34.9. foo.c.6. foo.c.7.'
while `*.c' would expand into `bar.c foo.c'.
To delete all files in a directory, you would have to type `rm *.'.
To copy them all, `cp *. otherdir'.
But `cp * otherdir' would be useful, copying the latest version of
each file to a new version in otherdir.

Received: from OFFICE-2.ARPA by MIT-MC.ARPA;  2 MAY 85 20:26:21 EDT
Received: from C39.Tymnet by OFFICE-2.ARPA;  2 May 85 17:24:20 PDT
Received: from tymix.Tymnet by C39.Tymnet; Thu, 2 May 85 17:24:06 PDT
Received: by tymix.Tymnet (4.12/4.7) id AA05086; Thu, 2 May 85 17:24:24 pdt
Return-path: <figmo@tymix.Tymnet>
From: figmo@tymix.Tymnet (Lynn Gold)
Date: Thu, 2 May 85 17:24:24 pdt
To: info-gnu@MIT-MC.ARPA
Message-id: <8505030024.AA05086@tymix.Tymnet>
Subject: Alternative help character

Reply-to: FIGMO@MIT-MC.ARPA

If "ESC-?" is so bad, how about "Control-X ?" instead?

I don't consider backspace=backwards-delete to be an unusual
binding; in fact, I know more people who consider it the norm
than not.

--Lynn

Date: Wed,  1 May 85 00:10:55 EDT
From: Richard M. Stallman <RMS@MIT-MC>
Subject:  Keep obscure subjects out of info-gnu.
To: sjk@SRI-SPAM
cc: INFO-GNU@MIT-MC
Message-ID: <[MIT-MC].478677.850501.RMS>

Please do not send discussions of technical details of
GNU Emacs to info-gnu.  I am afraid that if people do
this the volume of the mailing list will become too great
and mostly of little interest to most of the people on it.

Suggestions should not even be sent to info-gnu-emacs.
Send them to bug-gnu-emacs only.

If you have a reply to the suggestions that were sent,
please send it only to bug-gnu-emacs and the person
who you are responding to.

Received: from sri-spam.ARPA by MIT-MC.ARPA; 30 APR 85 22:11:44 EDT
Received: from localhost.ARPA by sri-spam.ARPA (4.22/4.16)
	id AA29039; Tue, 30 Apr 85 19:09:42 pdt
Message-Id: <8505010209.AA29039@sri-spam.ARPA>
To: figmo@score (Lynn Gold)
Cc: info-gnu@mit-mc.ARPA, bug-gnu-emacs@mit-prep, info-gnu-emacs@mit-prep
Subject: Re: problems with GNU EMACS
In-Reply-To: Your message of Tue, 30 Apr 85 17:29:58 pdt.
	     <8505010029.AA23920@tymix.Tymnet>
Date: 30 Apr 85 19:09:40 PDT (Tue)
From: sjk@sri-spam

[this message may not be of interest to some of the "info-*" readers]

Note that many elisp modules have documentation strings with default key
binding assumptions instead of dynamically determining the correct binding.
For example, in this excerpt from startup.el:

    (defun command-line-1 (args)

	   .	.	.

	   (insert ", Copyright (C) 1985 by Richard M. Stallman.
    It is freeware: you may copy and redistribute it under certain conditions.
    Type C-h C-c to see those conditions.
    Type C-h C-d for information on getting copies from me.\n")
	   (message "Type Control-h for help; Control-x u to undo changes")

	   .	.	.)

The point here is that if you start changing defaults, be sure to change
any references in the internal documentation, preferably in a generalized
manner.  I have been thinking about fixing other modules that are brain
damaged this way, especially in output from "describe-mode", but am not
sure of a good way of doing it.  Suggestions??

By the way, is there some way other than "etags" to determine which elisp
module a function is defined in?  I often find a bug in a function and
don't know how to easily find its source file.  Should this information
be internally available to Emacs and, if so, how?

Lastly, is there a way to determine which functions can be invoked with
"M-X <function>" and which must be invoked with "eval-expression" (or an
equivalent)?  Does use of the "interactive" call in a function determine
this property?  Sometimes I run "describe-function" on something that
catches my eye only to find out it can't be interactively invoked.
Perhaps <help>-d and <help>-k could distinguish this information?

Any comments are appreciated!!

scott

PS - Lynn... the "Tymnet" domain in "figmo@tymix.Tymnet" is not recognized
     by most mailers; you may want to add a valid "reply-to" field to your
     messages.

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 30 APR 85 21:50:12 EDT
Received: from LOGICON.ARPA by MIT-MULTICS.ARPA TCP; 30-Apr-1985 21:36:01-edt
Date: 30 Apr 85 18:25 PDT
From: Tom Perrine <tom@LOGICON.ARPA>
To: info-gnu%mit-mc@mit-multics
Cc: Tom Perrine <tom@logicon>
Subject: Re:  problems with GNU EMACS
In-Reply-To: Message from "andy@aids-unix (Andy Cromarty)" on 04/30/85 at 18:11

Actually, I think that the Multics Emacs ^_ (control-_) should
be help-on-tap. ^H is used in too many places for character erase,
in shells, etc.

Tom


Received: from aids-grape.ARPA by MIT-MC.ARPA; 30 APR 85 21:12:46 EDT
Date: Tue, 30 Apr 85 18:11:26 pdt
From: andy@aids-unix (Andy Cromarty)
To: figmo%tymix.Tymnet@aids-gateway, info-gnu@MIT-MC.ARPA
Subject: Re:  problems with GNU EMACS

As RMS noted in his release notes, ^H as "help" has a certain
measure of mnemonic value.  And anyway, users or installations
with an unusual binding for ^H or anything else can always rebind
to their heart's content -- it is EMACS, after all.

Note that ESC-? suffers from the specific problem that it's the
prefix for most keypad characters generated by many terminals
(VT52, H19, Visual 50, VT100 in VT52 mode, and lots of others).
Its use as a help character introduces some complications for
people who wish to create a keypad editor on top of EMACS, and
unlike the site-dependent problem you had, this one is based
on terminal hardware (i.e. it's not as easy to work around).

					asc

Received: from OFFICE-2.ARPA by MIT-MC.ARPA; 30 APR 85 20:32:29 EDT
Received: from C39.Tymnet by OFFICE-2.ARPA; 30 Apr 85 17:30:23 PDT
Received: from tymix.Tymnet by C39.Tymnet; Tue, 30 Apr 85 17:29:59 PDT
Received: by tymix.Tymnet (4.12/4.7) id AA23920; Tue, 30 Apr 85 17:29:58 pdt
Return-path: <figmo@tymix.Tymnet>
From: figmo@tymix.Tymnet (Lynn Gold)
Date: Tue, 30 Apr 85 17:29:58 pdt
To: info-gnu@MIT-MC.ARPA
Message-id: <8505010029.AA23920@tymix.Tymnet>
Subject: problems with GNU EMACS


Our site recently installed it.  Outside of there being no attached
documentation, there is one unanimous complaint: WHY IS THE HELP CHARACTER
"BACKSPACE?????"  Many Unix sites such as ours have the backwards delete
character default to backspace; in our case, since most of us use HP2621s
(where "delete" is "shift-ESC"), every time we try to rubout, we wind up
in the Help subsystem.  Since I'm one of the only two people at this site
who has had any real experience with Twenex Emacs, I dove in and managed
to undo this by setting backspace to be backwards-delete-character and
moving help back to Control-underline.  Since Control-X U also works as
"Undo," I lost no functionality.  Several people here feel that "ESC-?"
would be a MUCH more mnemonic help character; it is currently undefined.
I agree with them.

So, how about it?  Does anyone else out there agree with me, do you all
feel that Backspace should be the Help character, or is everybody typing
Control-O at this?

--Lynn Gold
  Tymnet, Inc.

ARPANET:  FIGMO@MC
UUCP:	  ...tymix!figmo




Received: from decwrl.ARPA by MIT-MC.ARPA; 28 APR 85 18:52:49 EDT
Received: by decwrl.ARPA (4.22.01/4.7.34)
	id AA29785; Sun, 28 Apr 85 15:53:27 pdt
Received: by amdcad.UUCP (4.12/4.7)
	id AA00804; Sun, 28 Apr 85 14:57:05 pdt
Date: Sun, 28 Apr 85 14:57:05 pdt
From: amdcad!phil@decwrl.ARPA (Phil Ngai)
Message-Id: <8504282157.AA00804@amdcad.UUCP>
To: decwrl!info-gnu@mit-mc.ARPA
Subject: insert character in gnu emacs

My version of gnu emacs doesn't seem to use the insert character feature
of my terminal. Is there anything I can do about this?

Date: Thu, 25 Apr 85 13:36:50 EST
From: Richard M. Stallman <RMS@MIT-MC>
Subject: Emacs LISP
To: PALLAS@SU-SCORE
cc: INFO-GNU@MIT-MC
Message-ID: <[MIT-MC].469802.850425.RMS>

This Lisp was once a separate program, and it has some
compilation conditionals to make it one again, but they
probably have bugs.  A few days of work could fix them.
I don't plan to work on this soon, because I think people
would find that it is not a very powerful Lisp and they would
find it necessary to do a lot more work to add what is
needed to have a real Lisp system.

I expect we will eventually (in a few months or a year)
have a free Common Lisp to use with GNU; so why bother
grooming the Lisp from GNU Emacs to compete with it?

But if a small weak Lisp is what you want, feel free to
fix the conditionals.  I will propagate your fixes.

Received: from UCB-VAX.ARPA by MIT-MC.ARPA; 24 APR 85 22:25:02 EST
Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.24/4.46)
	id AA12064; Wed, 24 Apr 85 19:22:16 pst
Received: by ucbdali.ARPA (4.24/4.46)
	id AA05213; Wed, 24 Apr 85 19:24:13 pst
Date: Wed, 24 Apr 85 19:24:13 pst
From: bh%ucbdali@Berkeley (Brian Harvey)
Message-Id: <8504250324.AA05213@ucbdali.ARPA>
To: info-gnu@mc
Subject: What "portability" means

I can't believe it.  I can't believe I'm hearing people say "go ahead and
use long names but make sure they're unique in the first six characters."
I guess all the people saying that have never had the pleasure of meeting a
BASIC interpreter that advertises "We have long variable names!  (But we
only look at the first two letters.)"

Why does one use long variable names in the first place?  Contrary to
popular opinion, it's not to show off one's touch typing skill.  It's to
make the program easier to read AND MODIFY because the names make sense.
If anyone working on a program is terrified to invent a new variable lest
it look unique but really conflict with something, that just introduces a
new source of hard-to-catch bugs.

The idea that we have to put up with this for "portability" is nonsense.
"Portability" means "GNU will run on lots of different machines."  You
are perhaps confusing this idea with "compatibility."  As I recall, the
only kind of compatibility anyone is claiming for GNU is "An application
written for Unix will run under GNU."  The reverse is not claimed.  Unix
is such a disgusting mess, it would be awful to have the chance to create
something better and pass it by.

Don't forget, gang, the object of this whole exercise is NOT to sell more
copies of Unix (TM).  The object is to get people out from under Unix.
That will happen because everyone starts using GNU instead >> because it's
a better operating system << (and also free).  Those who want to run GNU
utilities under Unix are faint-hearted.  (Those who want to run GNU utilities,
or anything else, under VMS have a problem I won't attempt to describe
because I made a resolution to be more polite this year.)

When this argument started I swore I wasn't going to get involved because
I'm tired of flaming and someone else would do it better.  But the past
few messages have been full of this "portability" sleight-of-hand and it
got me annoyed.  Sorry about that.

(The fact is, in my own programming I find InfinitelyLongVariableNames hard
to read and understand, especially if there is also something called
InfinitelyLongerVariableNames or something.  So I try to keep them short,
myself.  But I think the happy medium is somewhere above six.)

GNU.  It's the standard.

Received: from decwrl.ARPA by MIT-MC.ARPA; 24 APR 85 21:59:16 EST
Received: from DEC-RHEA.ARPA by decwrl.ARPA (4.22.01/4.7.34)
	id AA15305; Wed, 24 Apr 85 18:58:40 pst
Message-Id: <8504250258.AA15305@decwrl.ARPA>
Date: Wednesday, 24 Apr 1985 18:49:21-PST
From: minow%rex.DEC@decwrl.ARPA
To: info-gnu@mit-mc
Subject: Long variable names and the rest of us

As has been noted already, if GNU supports long multi-case global
variable names, programs will move to GNU without too much trouble.

Some of us, however, are bicultural and would like to use GNU
tools on other operating systems that support C compilers.
For example, I don't know of a yacc or lex that runs on VMS
(except for the Ratfor version from the Software Tools people).

If one of the goals of the GNU project is the production of portable
software, it might be wise to restrict global name usage for
utilities.

My understanding of the Draft ANSI Standard C work is as follows:

  1. internal identifiers are case-sensitive.  All characters are
     significant, but a compiler may choose not to deal with more
     than 31.

  2. External names MAY be restricted to 6-significant characters
     for some environments, and are case insensitive.

Flaming about other people's brain-damaged software is useless.  You
as a programmer must choose whether to make life easy for yourself
and hard for people moving your work elsewhere, or take a little
more care with your coding and make things much easier for those
who follow.

Martin Minow
minow%rex.dec@decwrl.arpa, decvax!minow

Received: from aids-grape.ARPA by MIT-MC.ARPA; 24 APR 85 21:17:57 EST
Date: Wed, 24 Apr 85 18:16:20 pst
From: andy@aids-unix (Andy Cromarty)
To: info-gnu@mit-mc
Subject: long names and Unix compatibility

It's important to remember *why* we want Unix compatibility.
Some candidate reasons are:

1. There's lots of Unix code out there, and if we build a Unix-compatible
   system, programs we've written for Unix will work under GNU.

2. We know how to use Unix to good advantage, and a Unix-compatible
   GNU means good carryover of our existing skills and knowledge.

3. Most of us find Unix to be a reasonably nice working environment.

None of these reasons excludes the introduction of additional non-Unix
features to GNU as long as GNU's functionality represents a strict
proper superset of Unix's.  So, for example, six-character-name
programs written under Unix will run under GNU as well as 120-character-name
programs will; compatibility in the sense of (1) above is thus preserved,
as are (2) and (3).

The only apparent goal that isn't satisfied by allowing GNU to use
long names or other non-UNIXisms is reverse portability, i.e. GNU ->
Unix ports.  But in many cases there are hacks around the specific
problems like the long-name problem.  For example, if your Unix C
compiler limits the length of function names and you have a GNU
program you'd like to compile using that Unix C compiler, you can
use M4 or the C preprocessor to replace long names with short
ones; this can involve as little as writing an include file with some
#define's in it.  Alternatively, if a specific Unix utility breaks when
it sees GNU names, you can run the GNU version of that program
instead (assuming there is one).

The real question is, "Why are you running Unix when you could be
running GNU freeware anyway, especially given GNU's performance
advantage?"  To paraphrase a decadent Frenchwoman of times past, "Let
them use GNU."

					asc

Received: from MIT-PREP by MIT-MC via Chaosnet; 24 APR 85  21:09:20 EST
Received: by MIT-PREP.ARPA (4.12/4.7) 
	id AA13859; Wed, 24 Apr 85 20:59:13 est
Date: Wed, 24 Apr 85 20:59:13 est
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: Easiest way to handle long names.

I intend the compiler and linker to deal with names of
any length and consider all characters significant.

It will be very easy to add a switch to the linker
to make it ignore all but the first six characters.
Whoever first wants to run a program which is written
with external names that differ after the fist six letters
and are supposed to be considered identical, can add this feature.

Since this takes care of any possible need to support ignoring
letters in names for standards' sake, I suggest that
we decide to ignore the problem until it is time to add
that linker feature.

I hope there will not be flaming on info-gnu about
length of variable names, or any stylistic issues.
I think that would create a volume of mail that would
make many people unhappy to be on it.

Received: from csnet-relay by MIT-MC.ARPA; 24 APR 85 20:49:27 EST
Received: from bostonu by csnet-relay.csnet id aa18596; 24 Apr 85 20:23 EST
Received: by bu-cs.ARPA (4.12/4.7)
	id AA04213; Wed, 24 Apr 85 19:58:56 est
Date: Wed, 24 Apr 85 19:58:56 est
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: info-gnu@MIT-MC.ARPA, rms@MIT-PREP.ARPA
Subject: Re:  No problem with long variable names

Ok, here we go....

Just because a variable name is long doesn't mean it has to
be ambiguous within, say, 8 characters (7 is safer.) You can,
within reason, have your cake and eat it too. One particularly
desirable way to accomplish both is to start variable names
(especially those external data and function ids which are
usually the only potential trouble as all Cs I know of handle
local long names, it's just the link editors) with some char or
two that identifies 'the package' they refer to, like
WM_current, WM_background, WM_headptr etc for a Window Manager
(all probably def'd in wm.h) and MS_curpos, MS_leftbutton etc
for a Mouse package (again, ms.h). At least makes it easier
to track down.

As to the basic issue of portability, if you throw out portability
you're gonna make it real hard for people to bootstrap GNU,
and is it really unreasonable for me to want to run only the
higher applications suite on, say, my IBM3081 for my students?
Or is a GNU kernal gonna be pre-requisite? Also, portability
is a lot of what makes any UNIX attractive...especially when
coupled with public domain code.

Far be it for me to preach software standards, but I think it's
worth a thought if there is no real lossage.

	-Barry Shein, Boston University

(anyone got GNUemacs running on their SYSV yet?)



Received: from SU-SCORE.ARPA by MIT-MC.ARPA; 24 APR 85 20:30:41 EST
Date: Wed 24 Apr 85 17:25:58-PST
From: Joseph I. Pallas <PALLAS@SU-SCORE.ARPA>
Subject: Emacs LISP
To: info-gnu@MIT-MC.ARPA

Are there any plans to split off the LISP interpreter into a separate
program?
-------

Received: from MIT-MULTICS.ARPA by MIT-MC.ARPA; 24 APR 85 20:19:14 EST
Received: from LOGICON.ARPA by MIT-MULTICS.ARPA TCP; 24-Apr-1985 20:16:10-est
Date: 24 Apr 85 17:06 PST
From: Tom Perrine <tom@LOGICON.ARPA>
To: info-gnu%mit-mc@mit-multics
Cc: Tom Perrine <tom@logicon>
Subject: Re: Standards for GNU system code (long names)

Not to beat this horse any further, but I personally think that long
ids are a good idea.  However some sites just wont be able to hack it
(older un*x versions, bad ports, etc.)

I think that the priorities are:

Human readable

GNU-compatible

some kind of un*x compatibility, probably 4.x

For this reason, I vote for long names. If someone want to run GNU utilities
(because they are better?!?), then let him worry about it.

I would also suggest a tool that scans the program, generating
GUARANTEED unique names i.e.  ID0001.  Let the guy with the
brain-damaged compiler figure it out.  By the way, I have a
brain-damaged compiler (PWB), and I realize I will have problems, but I
am willing to live with that problem now in hopes of a better system in
the future.

Tom Perrine
Logicon - OSD


Received: from MIT-CCC by MIT-MC via Chaosnet; 24 APR 85  19:37:12 EST
Date: 24 Apr 1985 19:35:24-EST
From: jfw at MIT-CCC
To: info-gnu@MIT-MC.ARPA, rms@MIT-PREP.ARPA,
    root@BOSTONU.CSNET@CSNET-RELAY.ARPA
Subject: Re:  Standards for GNU system code

The proposed ANSI C standard has 6 letter monocase externals, despite much
discussion, thanks to the brain-death of too many mainframes.  On the other
hand, 6 letter externals is an even greater pain in the ass.  Perhaps we
could make everyone happy be creating a tool which alters long names after
compilation and before final linking.  This is hard to design right, perhaps,
but as one who has read and written too much FORTRA code, I would much rather
code with reasonable length names.  After all, variable names are really for
human convenience, not the computer's!

	-John Woods

That's right, I said FORTRA.

Received: from csnet-relay by MIT-MC.ARPA; 24 APR 85 18:42:52 EST
Received: from bostonu by csnet-relay.csnet id ad17062; 24 Apr 85 15:19 EST
Received: by bu-cs.ARPA (4.12/4.7)
	id AA00628; Wed, 24 Apr 85 14:57:11 est
Date: Wed, 24 Apr 85 14:57:11 est
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: info-gnu@MIT-MC.ARPA, rms@MIT-PREP.ARPA
Subject: Re:  Standards for GNU system code

Richard,

Agreed, just a couple of thoughts:

	1. We ran into this formatting problem on a project
	and the solution I came up with was to just silently
	take code and put it through the C pretty printer
	(cb) rather than trying to convert people
	(convert code not people!), nasty habits die hard.

	2. In addition, I would think *real* hard about long
	variable names, they are an incredible nuisance.
	System V arbitrarily truncates them for no good reason,
	TOPS-20 chops them hopelessly to 6 (maybe this is an
	abberant case), IBM systems will never give up 8 char
	ids [all this chopping is done in the link-editors.]
	What happens often is they either create lotsa link
	time errors or worse (usually when you think you nailed
	them all) dispatch tables dispatch wrong having silently
	resolved to one ambiguity or another.

Someone here suggested a utility to 'fix' code that already
uses long names: The idea was to write, say, an awk program
which truncates at MAXVARNAME-1 and fills in the last character
with a character generated from the ones you chopped off,
kind of a checksum character in the hope it then makes it unique.
I am not sure how hard this is, probably could be built out
of a C pre-processor as it already has to get all the name tokens.

	-Barry Shein, Boston University



Received: from MIT-PREP by MIT-MC via Chaosnet; 24 APR 85  15:48:30 EST
Received: by MIT-PREP.ARPA (4.12/4.7) 
	id AA12039; Wed, 24 Apr 85 15:36:41 est
Date: Wed, 24 Apr 85 15:36:41 est
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: No problem with long variable names

Writing GNU system code is not the same as writing maximally
portable Unix code.  GNU is one operating system, and GNU code
need only run on the GNU kernel with the GNU compiler.  Running
GNU utilities on Unix is only a temporary measure for debugging
those utilities.  Whether the utilities would run on any particular
Unix version in addition to GNU is not relevant to the GNU project.

Since the GNU compilers and linker will all support long names,
I encourage people to use them.  It makes programs clearer.



Received: from MIT-PREP by MIT-MC via Chaosnet; 24 APR 85  15:48:30 EST
Received: by MIT-PREP.ARPA (4.12/4.7) 
	id AA12039; Wed, 24 Apr 85 15:36:41 est
Date: Wed, 24 Apr 85 15:36:41 est
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: No problem with long variable names

Writing GNU system code is not the same as writing maximally
portable Unix code.  GNU is one operating system, and GNU code
need only run on the GNU kernel with the GNU compiler.  Running
GNU utilities on Unix is only a temporary measure for debugging
those utilities.  Whether the utilities would run on any particular
Unix version in addition to GNU is not relevant to the GNU project.

Since the GNU compilers and linker will all support long names,
I encourage people to use them.  It makes programs clearer.



Date: Tue, 23 Apr 85 23:33:33 EST
From: Richard M. Stallman <RMS@MIT-MC>
Subject: m4 questions answered
To: INFO-GNU@MIT-MC
Message-ID: <[MIT-MC].467213.850423.RMS>

jfw@ccc answered the questions, so there is no need
for anyone else to do so.

Received: from MIT-CCC by MIT-MC via Chaosnet; 23 APR 85  22:00:57 EST
Date: 23 Apr 1985 22:00:47-EST
From: jfw at MIT-CCC
To: info-gnu@MIT-MC, rms@MIT-PREP
Subject: Re:  Questions on `m4'

	From rms@mit-prep Tue Apr 23 21:11:37 1985
	Date: Tue, 23 Apr 85 20:49:31 est
	From: Richard M. Stallman <rms@mit-prep>
	To: info-gnu@mc
	Subject: Questions on `m4'
	
	The person writing a replacement for m4 has no access to try it
	and has some questions on how it should work.
	
	1) Is "undiverted" text re-scanned?
No.  It is scanned going in to the diversion, but not scanned coming
back out (this from the M4 reference manual and experimentation).

	2) What happens if you try to divert text to the channel
	 from which you are currently "undiverting"?
Because undiverted text is not scanned for macros, you cannot do this.
It seems to be harmless to say:

divert(1)
  This is the text going into the diversion
  divert(1) Just to be annoying.

The remaining text is appended (which is what the manual specifies).
Note that the extra divert(1) happens on input to the diversion.

	3) Should `m4' object if the number of arguments is wrong,
	 or just carry on with null arguments?
	
M4 just loves to have incorrectly numbered arguments.  Referring to
non-given arguments yields null strings.  Giving too many cannot even
be detected, given the way M4 works.

Have fun, and happy macros!

Received: from MIT-PREP by MIT-MC via Chaosnet; 23 APR 85  21:58:29 EST
Received: by MIT-PREP.ARPA (4.12/4.7) 
	id AA05925; Tue, 23 Apr 85 21:54:32 est
Date: Tue, 23 Apr 85 21:54:32 est
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: awk

The person who was writing `awk' gave up with it half finished.
He has no time to finish it.
Will anyone volunteer to take over the project?

Received: from MIT-PREP by MIT-MC via Chaosnet; 23 APR 85  20:58:40 EST
Received: by MIT-PREP.ARPA (4.12/4.7) 
	id AA05134; Tue, 23 Apr 85 20:46:17 est
Date: Tue, 23 Apr 85 20:46:17 est
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: Current status of GNU project

General Summary of GNU Tasks
(Detailed lists of utility, library and documentation projects
 available on request.)

1) Writing the kernel.

A couple of additional experienced system writers could be
helpful here; but they need to be in Boston or at least
on the Arpanet in order to be able to take part.  We are using
a message-passing architecture on top of which Unix system
calls will be implemented by libraries.

2) Writing the new compiler.

Although I have a portable C and Pascal compiler, it has a
serious drawback: it is a very large program, and intrinsically
cannot be made smaller.  It is also very hard to bootstrap.
Therefore, I plan to switch to a new compiler.  Most of this
compiler has already been written (by Chris Pettus), but
code generators are needed, and so are front ends for languages
other than C.  Chris expects to send me soon a document
describing the interface to code generators.  This is a
very important project.

3) Writing a source-level debugger.

It would be nice to have a new debugger for two reasons:
dbx has many deficiencies, and dbx may not be available for
GNU to distribute.  This is a large project, but not as
hard as the compiler because efficiency is not so important.

4) Writing nroff-related utilities.

Part of nroff has been written and the rest of it is being
worked on, but the related utilities such as eqn and tbl,
and duplicates of the standard macro packages, need to be written.

I do not have a high opinion of nroff, and plan to distribute
tex as well.  But nroff, etc, are important to have for compatibility.
These are medium size projects, a little tricky to get right
because `right' means balancing `compatible enough to do the right thing
with people's actual source files' with `not having the the stupid bugs
of the originals'.

5) Data base software.

I've never used a data base system, so I don't really know what
they do.  But since so many people want one, it is a good thing
to contribute to GNU.  A data base system would be more useful
if it could accept as input the data bases used by other widely
used data base systems such as dbase.  A compatible command
language might be a good idea, but you might also be able to
design a superior command language.

6) Graphics software.

It is not clear what sorts of graphics software there ought to
be for GNU.  A package for drawing in three dimensions with
clipping and rotation would certainly be desirable.  Graph-drawing
packages will also be useful.  Someday there will be a window
system for GNU, and I have a lot of ideas on designing this,
which I will tell you if you want to work on such a thing.

If you are interested in working on graphics, ask me to put you
in touch with other people who are.

7) Writing other utilities.

There are still some other utilities needed.  These projects range
from small to medium-large, and do not require much communication
with the rest of the GNU project; just send it when it is done.  No
especial commitment is needed: if you give up, eventually I'll find
someone else to do it.

However, the remaining unfinished utilities are mostly
not vital ones, just nice to have.

You should also write a document for a utility you write.

8) Adapting, improving or finishing utilities.

There are a few utilities that have been partially finished, or which
exist but lack some of the needed features.  Finishing or Extending a
utility is the same sort of project as writing a new utility, with
one difference: I will have to send you the stuff to start with.  If
you can get it over a network, that's easy.  If not, I'm willing to
send you the existing utility's code to start with, but this is a lot of
work, so please ask only if you are really going to do the job.

Utilities needing work include ar (finished except for one
tricky part), awk (half finished), diff (needs features),
grep (needs features), lex (needs conversion from ratfor to C),
ls (needs features), sed (needs elimination of arbitrary limits).

9) Writing libraries.

Most of the standard C library functions are still needed.
They fall into two classes: a) stdio and b) everything else.

stdio is a medium size project that is very important and needs
a lot of care.  It is important that the person writing stdio
promise to get it finished.

The other libraries are small to medium projects, about like
writing random utilities.

You should also write a document for a library you write.

10) Major Documentation Projects

Documentation needs to be written for these programs:

awk, csh, ed, eqn, lex, ls, make, nroff, sh, tbl, yacc.

These are significant documentation projects.
Documentation should be written in a language called
"texinfo", which can serve as tex input using a special macro package,
and can also be turned into info files for on-line reference
using a special program.

11) Converting documentation

Many existing documentation files are either in nroff format
or are just text files.  They need to be converted to texinfo.
This is pretty easy to do, but you need to get the originals.
The comments about sending code for unfinished utilities
(see 8, above) apply here.



Current Status of the Compiler.

  I have a compiler that accepts two input languages,
C and Pastel ("off-color Pascal", extended to be as powerful
as PL/I), and capable of generating code for Vaxes, 68000's,
and a few other machines.

 It runs reasonably fast, faster than the Unix C compiler, and makes
somewhat better code on the Vax at least.  It also contains an
automatic register packer so that there is no need (or use) for
register declarations.

  Unfortunately, the compiler is also very hairy, with 400k
bytes of code alone on a vax.  Also, it uses gigantic amounts
of data during execution, because it never reuses any storage
that it allocates dynamically, during the compilation of an
entire file.  It can use 2 mbytes compiling a large file.
This is unimportant for use on a machine with virtual memory,
since the working set is much smaller than that, but it makes
the compiler useless for many smaller machines that could otherwise
run GNU.

  The reason that the compiler is so big is that it was written
to compile Pastel, which is a hairy language.  I got the Pastel
compiler free and added the C front end and the 68000 code generator.

  It would be possible to make the compiler much smaller by
eliminating the ability to compile all the hairy constructs of
Pastel.  Unfortunately, this creates another problem: most of the
compiler is written in Pastel, and there would be no way to compile
it.  So it would also be necessary to rewrite it all into C.

  Aside from this, the compiler currently needs a few days work 
to be working properly for the Vax again.  It cannot currently
run on anything but Vax Unix, since there is no way to run
Pastel code on any other system until the compiler is fully bootstrapped
to that system via cross-compilation on the Vax.

  Chris Pettus and Velu Sinha are interested in working on solving the
compiler's problems by replacing it with a new optimizing C compiler.
People with experience in compilers could help in the effort; most
easily if they are near L.A. or D.C.

  If you are interested in this, call Chris Pettus at
(213) 202-8925, or Velu Sinha at (301) 699-8155.



GNU Emacs

This is the only part of the GNU project that is really
useful by itself, because it does not duplicate a standard
part of Unix.  GNU Emacs contains a true Lisp, with byte
compiler, for extensibility.  It now runs on Vaxes and 68000's
under 4.2, and possibly has been ported to other machines as well.
I expect it to be ported to nearly all Unix systems on machines
with 1meg or more of either virtual or physical memory.



GNU kernel

Implementation of the kernel began in late March.
We are using a message-passing architecture on top of which
Unix system calls will be implemented by user libraries.
This will make the GNU kernel technically more advanced than
Unix, and will also make the GNU internals radically different
from Unix, thus eliminating any danger of parallel design
that might be used by AT&T as an opening for legal interference.

We are using a design somewhat in the spirit of Accent (CMU),
but with added primitive features to improve the efficiency
of simulating Unix accurately.

The kernel is now expected to run on both virtual and nonvirtual
memory systems, and possibly even on 16-bit machines.
It will support tightly-coupled multiprocessor systems and also
transparent distributed operation across local networks.

Received: from MIT-PREP by MIT-MC via Chaosnet; 23 APR 85  20:58:34 EST
Received: by MIT-PREP.ARPA (4.12/4.7) 
	id AA05150; Tue, 23 Apr 85 20:50:39 est
Date: Tue, 23 Apr 85 20:50:39 est
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: Standards for GNU system code

If you have any suggestions on this topic, please tell me.


Formatting standards:

It is important put the open-brace that starts the body of a C function
in column zero, and avoid putting any other open-brace or open-parenthesis
or open-bracket in column zero.  Several tools look for
open-braces in column zero to find the beginnings of C functions.
These tools will not work on code not formatted that way.

It is also important for function definitions to start the name
of the function in column zero.  `ctags' or `etags' cannot recognize
them otherwise.  Thus, the proper format is

static char *
concat (s1, s2)        /* Name starts in column zero here */
     char *s1, *s2;
{		       /* Open brace in column zero here */
  ...
}

Aside from this, I prefer code formatted like

  if (x < foo (y, z))
    haha = bar[4] + 5;
  else
    {
      while (z)
        {
	  haha += foo (z, z);
	  z--;
        }
      return ++x + bar ();
    }

but it is not an important issue.


Commenting Standards:

Please put a comment on each function saying what the function does,
what sorts of arguments it gets, and what the possible values
of arguments mean and are used for.  It is not necessary to duplicate
in words the meaning of the C argument declarations, if a C type is
being used in its customary fashion.  If there is anything nonstandard about
its use (such as an argument of type char * which is really the address
of the second character of a string, not the first), or any possible values
that would not work the way one would expect (such as, that strings
containing newlines are not guaranteed to work), be sure to say so.

There should be a comment on each static variable as well, such as

/* Nonzero means truncate lines in the display; zero means continue them */

int truncate_lines;


Syntactic Standards:

Please explicitly declare all arguments to functions.
Don't omit them just because they are ints.


Semantic Standards:

Avoid arbitrary limits on the length or number of ANY data structure,
including filenames, lines, files, and symbols, by allocating all
data structures dynamically.  In most Unix utilities, "long lines
are silently truncated".  This is not acceptable in a GNU utility.

Utilities reading files should not drop null characters, or any other
nonprinting characters including those with codes above 0177, except
perhaps those specifically intended for interface to printers.

Check every system call for an error return, unless you know you
wish to ignore errors.  Include the system error text (from perror
or equivalent) in EVERY error message resulting from a failing
system call, as well as the name of the file if any and the
name of the utility.  Just "cannot open foo.c" or "stat failed"
is not sufficient.

Check every call to malloc or realloc to see if it returned zero.
In Unix, realloc can destroy the storage block if it returns zero.
GNU realloc does not have this bug, so your utilities can assume
that realloc works conveniently (does not destroy the original
block when it returns zero.)  If you wish to run them on Unix,
and wish to avoid lossage in this case, you can use the GNU malloc.

When static storage is to be written in during program execution,
use explicit C code to initialize it.  Reserve C initialized
declarations for data that will not be changed.

Try to avoid low-level interfaces to obscure Unix data structures
(such as file directories, utmp, or the layout of kernel memory),
since these are less likely to work compatibly.  If you need to
find all the files in a directory, use `readdir' or some other
high-level interface.  These will be supported compatibly by GNU.

GNU signal handling will probably be like that in 4.2, rather than
that in system V, because 4.2's is more powerful and easier to use.

Received: from MIT-PREP by MIT-MC via Chaosnet; 23 APR 85  20:58:30 EST
Received: by MIT-PREP.ARPA (4.12/4.7) 
	id AA05142; Tue, 23 Apr 85 20:49:31 est
Date: Tue, 23 Apr 85 20:49:31 est
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: Questions on `m4'

The person writing a replacement for m4 has no access to try it
and has some questions on how it should work.

1) Is "undiverted" text re-scanned?
2) What happens if you try to divert text to the channel
 from which you are currently "undiverting"?
3) Should `m4' object if the number of arguments is wrong,
 or just carry on with null arguments?

Received: from UCB-VAX.ARPA by MIT-MC.ARPA;  5 APR 85 04:43:46 EST
Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.24/4.42)
	id AA26101; Fri, 5 Apr 85 01:43:35 pst
Received: by ucbernie.ARPA (4.24/4.42)
	id AA24257; Fri, 5 Apr 85 01:44:11 pst
Date: Fri, 5 Apr 85 01:44:11 pst
From: phr%ucbernie@Berkeley (Paul Rubin)
Message-Id: <8504050944.AA24257@ucbernie.ARPA>
To: info-gnu@mit-mc
Subject: gnu's letter

Gnu's Letter: Sally Walker and Krishna Vattam, Editors.
$15/year (12 issues) from
	Gnu's Letter
	c/o Mysore Zoo
	Mysore-10, India

"The beginnings of an Asian Indian educational and conservation
magazine.  For the moment, lots of zoonooz but hopefully expanding
to cover national parks and the needs of the Malabar rain forest,
the monsoon forests, and Thar deserts."


				---Peter Warshall
				   Whole Earth Review, May 1985

Received: from maryland.ARPA by MIT-MC.ARPA; 22 MAR 85 09:12:10 EST
Received: by maryland.ARPA (4.12/4.7)
	id AA00933; Fri, 22 Mar 85 09:11:28 est
Date: Fri, 22 Mar 85 09:11:28 est
From: Velu Sinha <velu@maryland>
Message-Id: <8503221411.AA00933@maryland.ARPA>
To: clp.pa@XEROX.ARPA, velu@MARYLAND.ARPA
Subject: Re: Regular Expressions
Cc: info-gnu@MIT-MC.ARPA

Thanks/

Received: from Xerox.ARPA by MIT-MC.ARPA; 22 MAR 85 00:40:09 EST
Received: from Semillon.ms by ArpaGateway.ms ; 21 MAR 85 21:39:03 PST
Date: Thu, 21 Mar 85 21:21:59 PST
From: clp.pa@XEROX.ARPA
Subject: Re: Regular Expressions
In-Reply-To: <8503152349.AA09125@maryland.ARPA>
To: Velu Sinha <velu@MARYLAND.ARPA>
cc: info-gnu@MIT-MC.ARPA

There is a PWB (from ~ V6 days) UNIX version of this functionality that
you could look at; I believe it was in section 3 under the names
regex(3), compex(3), ...

It first compiled the string into an internal form and then executed it
repeatedly onto the (presumably large) search string.

									Charles Perkins

Received: from maryland.ARPA by MIT-MC.ARPA; 16 MAR 85 08:12:05 EST
Received: by maryland.ARPA (4.12/4.7)
	id AA02211; Sat, 16 Mar 85 08:10:56 est
Date: Sat, 16 Mar 85 08:10:56 est
From: Velu Sinha <velu@maryland>
Message-Id: <8503161310.AA02211@maryland.ARPA>
To: RMS@MIT-MC
Subject: Re:  Regular Expressions
Cc: INFO-GNU@MIT-MC

Great!

Date: 15 March 1985 19:48-EST
From: Richard M. Stallman <RMS @ MIT-MC>
Subject: Regular Expressions
To: velu @ MARYLAND
cc: INFO-GNU @ MIT-MC

I have already written a regex library.
It can be found in /u/rms/gnulib/regex.{c,h}
with documentation in /u/rms/gnudoc/regex.doc
It is used in GNU Emacs and therefore has been tested a lot.
Anyone can feel free to use it now.

Received: from maryland.ARPA by MIT-MC.ARPA; 15 MAR 85 18:50:55 EST
Received: by maryland.ARPA (4.12/4.7)
	id AA09125; Fri, 15 Mar 85 18:49:37 est
Date: Fri, 15 Mar 85 18:49:37 est
From: Velu Sinha <velu@maryland>
Message-Id: <8503152349.AA09125@maryland.ARPA>
To: info-gnu@mc
Subject: Regular Expressions



I have been thinking of implementing a regex() function, a function
which would handle all of the generic pattern matching problems which
tend to crop up. 

I would like some comments on possible formats for passing arguements
to this function: My own personal preference at this point is
	char *regex(expression,strings)
	char *expression, **strings;

Is this adequate? Is there someother format which would be better?

Thanks...



Date: 9 March 1985 00:09-EST
From: Richard M. Stallman <RMS @ MIT-MC>
Subject:  debugger exists, kernel somewhat; meeting?; "common" object file fmt
To: INFO-GNU @ MIT-MC

I recently found out about a free stand-alone portable DDT,
so I won't have to write one.  Also, Wegrzyn or ENcore computer
has a message passing kernel to give me.  It's not Unix
compatible as it stands, but adapting it may be easier than
starting from scratch.  I have yet to see it, though.

I have been continuing to improve GNU Emacs, and now am
nearly finished with it.

I'll be in CA at the end of March.  Is anyone interested
in having another West Coast GNU Meeting?

I recently saw that the System V object file format is called
"the common object file format".  Its documentation has vague
hints that it may be shared with non-Unix systems.  If true,
perhaps this means that there is a free document describing it.
Does any one know the story behind this?

From encore!wegrzyn  Mon Feb 25 08:19:42 1985 remote from ultravax
Received: by ultravax.UUCP (4.12/4.7)
	id AA09257; Mon, 25 Feb 85 08:19:42 est
Received: by encore.UUCP (4.12/4.7)
	id AA00420; Mon, 25 Feb 85 08:08:33 est
Received: by encore.UUCP (4.12/4.7)
	id AA00417; Mon, 25 Feb 85 08:08:25 est
Date: Mon, 25 Feb 85 08:08:25 est
From: ultravax!encore!wegrzyn (Chuck Wegrzyn)
Message-Id: <8502251308.AA00417@encore.UUCP>
To: INFO-GNU@MIT-MC.ARPA
Subject: Info about GNU


	Can you give me info about GNU? Such as the availability of
	it, whether or not help is needed ( I am in the Boston area),
	etc? How about a local phone number to call to find info?

		Chuck Wegrzyn
		{allegra,decvax,ihnp4}!encore!wegrzyn

Received: by mit-eddie.Mit-chaos.Arpa id AA08443; Tue, 12 Feb 85 04:10:54 est
Date: 12 Feb 1985 03:51-EST
From: teddy-bear!mrose@mit-eddie
Subject: 68000 UNIX development machine avail.
To: mit-eddie!info-gnu@mc

Financial circumstances beyond my control are forcing me to sell the
following system:

Pixel-80 68000-based microcomputer, 2M RAM, 65M Maxstor hard disc,
Kennedy cartridge tape drive (for backup *and* accessible as a regular
device), 8 serial ports, floppy drive, 4.2-ish system, Berkeley style
news.  A price quote today on this system new from Pixel was ~$26,500.
It's nine months old, and we've never had any problems with it.  

In addition, my LSI Adm-42 and Unipress EMACS, (with sources) go with
it too.  We also have both Rogue & Rogomatic up, with source, and if
you wann'em, they're yours.  The terminal and Emacs are worth $1800.
(There is also a working EMACS from some old public domain source,
which we copied from MIT-PREP {I can't imagine how it got there ;-> },
running just fine.  Of course it could use some mlisp enhancements, but
so can't we all. )

I am asking $20,500,  considering I've enjoyed the use of it for nine
months, but am willing to negotiate, esp. if it will help GNU.  I
cannot afford to donate it or anything, as I still owe over $10K on it.
Sorry.  This is a really nice reliable machine and I am pretty upset at
having to part with it.  Call me at (617) 738-8197 anytime after 9 am
and before 11 pm, or send mail to MROSE@MC (or mit-eddie!teddy-bear!mrose)

Martha Rose



Received: by cvl.ARPA (4.12/4.7)
	id AA26284; Fri, 25 Jan 85 15:40:00 est
Date: Fri, 25 Jan 85 15:40:00 est
From: liang@cvl (Eli Liang)
Message-Id: <8501252040.AA26284@cvl.ARPA>
To: info-gnu@mit-mc
Subject: "as" for gnu

Could someone tell me what the 68000 assembler for gnu will be and where I
can find a copy?

-eli


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Eli Liang  ---
        University of Maryland Computer Vision Lab, (301) 454-4526
        ARPA: liang@cvl, eli@mit-mc, eli@mit-prep  CSNET: liang@cvl
        UUCP: {seismo,allegra,brl-bmd}!umcp-cs!cvl!liang


Received: from bostonu by csnet-relay.csnet id ab10961; 16 Jan 85 12:12 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA01515; Wed, 16 Jan 85 11:34:04 est
Date: Wed, 16 Jan 85 11:34:04 est
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: evan@ccc.arpa, info-gnu@MIT-MC.ARPA
Subject: Re:  The Shell Game...


	I think there is nothing wrong with the concept of an
	abbreviation facility but I am troubled by the following:

		a) If you wanted a short name why don't you
		use a short name? or a better name in the case
		of case confusion.

		b) The link and symbolic link facilities make it
		easy to have more than one name for a file
		(the latter approaching the abbreviation facility.)

		c) There are also shell variables

		set tiavlfn=ThisIsAVeryLongFileName

		vi $x

		which you can put into a .login file (or a .*rc file
		which would be more appropiate.)

		'$' is not the easiest key to hit (picky picky) maybe
		just make that metacharacter settable, trivial and
		non-disruptive (',' comes to mind "vi ,x")

I guess the point is that adding syntactic sugar should be looked at
very suspiciously as "there madness lies".

		-Barry Shein, Boston University



Received: from bostonu by csnet-relay.csnet id a010961; 16 Jan 85 12:12 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA01219; Wed, 16 Jan 85 11:19:31 est
Date: Wed, 16 Jan 85 11:19:31 est
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: INFO-GNU@MIT-MC.ARPA, RMS@MIT-MC.ARPA, alt@SRI-TSCA.ARPA
Subject: Re:  Dynamic linking.


	I don't think a special compiler mode is really necessary.
	I think all that really needs to be done (hah! ALL!?!)
	is three versions (maybe two would do) of the link
	libraries. One obviously could have what we have now.
	One has the externals defined to routines that would
	be something like:

	fopen(file,mode) char *file, *mode ;
	{
		static BOOL FirstTime = 1 ;
		static FILE *(*LoadedFopen)() ;	/* forgive minor errors here */

		if(FirstTime)
		{
			FirstTime = 0 ;
			LoadedFopen = DynamicallyLoad("_fopen") ;
		}
		return((*LoadedFopen)(file,mode)) ;
	}

	The third would be in a format convenient for
	the DynamicallyLoad() routine (or maybe it just
	knows how to use the normal library.)

	If they were shared, resident libraries then change
	the name of DynamicallyLoad() to DynamicallyBind().

	OK, maybe I am being picky. You would have to tell
	ld which library to load (-lshared).

		-Barry Shein, Boston University


Date: 15 Jan 85 20:43:17 PST (Tue)
From: Andy Cromarty <andy@aids-unix>
Subject: Modifying Unix
To: info-gnu@mit-mc

The most prudent (and, probably, the easiest) development path for GNU
can probably be captured in the simple design principle:

	"Leave UNIX alone."

There is an enormous body of software with which we will want to
remain compatible.  Changing the structure of directory files, the
operation of csh (but not "gsh"), the default behavior of common
pattern matching subroutines, etc. is inviting disaster.  And
unnecessarily so: it is entirely consistent with the Unix "tool"
philosophy for us to *augment* Unix by providing additional tools
(a new "ls," "ar," "grep," what have you) that has All Those Neat
Features We Can't Live Without that everyone keeps dreaming up.

Yes, UNIX has design flaws.  But they are venerable by now, and lots
of software relies on just those flaws.  Once we have a core UNIX
system written, there will be plenty of time for everyone to write
their own competitive versions of, say, grep, and may the best tool
win.  But if the standard grep utility doesn't work the way people
expect because its implementor had a great idea about how to "fix"
it, we lose big.  In particular, we lose one of the two main assets
of GNU: that it really does work just like UNIX.

For those who cannot live without their Favorite Neat Feature, you
can take advantage of the second GNU asset: The source is publicly
available without charge, so you can use the existing GNU grep source
to base your version on, and then distribute it without risking a law
suit.  "gsh" is an excellent example of how you can implement a
competitive software tool that can provide functionality people want
without damaging existing tools.  There should be nothing at all
wrong with having gsh be case-insensitive -- or even reverse the case
of every other letter, for that matter -- as long as the user can
invoke a Bourne shell and/or csh that handle the pre-existing scripts
we all currently rely on.

Many of you will recall that we covered this ground in agonizing
detail at the (annual?) GNU organizational meeting at AI&DS last
year.  For those who were not present, my understanding of the
concensus that emerged is that GNU should differ from UNIX "no more
than UNIX differs from itself" in its current two implementations
(Berkeley and Bell), if that much.  In other words, everything should
be compatible for the average code writer, down to most or all system
calls but not necessarily below that.  That still seems like a good
plan to me.

					asc

Date: 15 January 1985 22:31-EST
From: Richard M. Stallman <RMS @ MIT-MC>
Sender: RMS0 @ MIT-MC
To: INFO-GNU @ MIT-MC

I believe that a clean way of making case-depence optional
is to assign a flag to each directory
controlling whether case is significant in files in
that directory.  open would ignore case when looking
up files in directories that say to do so.
Creating a file would create with whatever case
was specified.

However, I'm not sure it is really important to do this.
It might be better just to use lower case letters in file names.
Filename completion does more to ease typing of long names
than case-independence does.

Received: by cvl.ARPA (4.12/4.7)
	id AA07048; Tue, 15 Jan 85 20:48:13 est
Date: Tue, 15 Jan 85 20:48:13 est
From: liang@cvl (Eli Liang)
Message-Id: <8501160148.AA07048@cvl.ARPA>
To: info-gnu@mit-mc.ARPA
Subject: Compiled shell scripts in GSH


As one of the people working on the shell script handler for GSH, I can say
that GSH will definitely have provisions for at least semi-compiled shell
scripts (the way we handle it in the shell is actually fairly simple).
Unfortunately, by the nature of shell scripts, I doubt that any significant
improvement in efficiency or speed will come of it in most applications
which shell scripts are now used.  Since the syntax of the shell scripts
are actively being worked out now, changes can be easily accommodated so
feel free to suggest improvements/extensions/changes to standard csh-like
syntax.  I think however that only extensions should be contemplated for the
sake of compatibility.

-eli liang
(liang@cvl.arpa)

Date: 15 Jan 1985 19:03:56-EST
From: evan at CCC
To: info-gnu@MIT-MC
Subject: The Shell Game...
Cc: mit-eddie!frog!wjr@CCC, syspeople@CCC


	Look guys, it's all really very simple. I've seen the future, and
it works.

	What you want are MULTICS style abbrevs. That is, you want a list
of short names that substitiute to long names defined in some magic file.

	When I worked at Chuck River Data Systems, we had a shell that did
just that. You used little built in commands to define abbrevs, and they
were stored in a permanent data base, that worked accross logins.

	There were global abbrevs, that worked all the time, and local ones
that worked only in a given directory. The global ones were defined in the
.globals file in your home directory, and the local ones were defined in a
.locals file in the local directory.

	There were abbrevs that work at the beginning of the line, like csh
aliases, and there were abbrevs that expanded everywhere in the line, so
you could abbreviate Thisisaverylongfilename to tiavlfn or something, and
then type:

% vi tiavlfn

and then vomit because you are using vi.

	I think this is easy to do. What do you folks think?




					Evan Williams
					evan%ccc@mc

Date: 15 January 1985 18:00-EST
From: Richard M. Stallman <RMS @ MIT-MC>
Subject: Dynamic linking.
To: INFO-GNU @ MIT-MC, alt @ SRI-TSCA

Given the existence of malloc, it is not very hard
for a user to implement dynamic linking.  The main
thing that has to be done is establish the conventions
for finding the locations of entry points by searching
the a.out symbol table somehow or by some other method.

Making it able to load libraries shareably, or mostly so,
is somewhat harder, but again, since there is only one
malloc, it can be informed somehow of the memory that is
used for libraries and symbol tables.  It would be
necessary to have a special compiler mode so that all
external references could go indirect, so that the text
of a library containing external references could be shared.

It would also be possible to have a segment containing the
standard libraries mapped into everyone's address space
at a fixed location.  This is not very hard to do.

None of these is a very high priority, since they are not
needed to equal Unix, and there is not much danger of
making them impossible by doing something the wrong way.

Received: by utah-cs.ARPA (4.42/4.40.1)
	id AA15421; Tue, 15 Jan 85 15:11:59 MST
Date: Tue, 15 Jan 85 15:11:59 MST
From: lepreau@utah-cs (Jay Lepreau)
Message-Id: <8501152211.AA15421@utah-cs.ARPA>
To: info-gnu@mit-mc
Subject: Re:  idea for Gnu shell

This has got to be one of the dumbest ideas I've seen in a quite a
while.  Either filenames are case sensitive or insensitive, at all
levels.  Putting one thing in the shell and another in the kernel &
filesys is crazy and would lead to endless problems.

If you want GNU to look like Unix, or if you want to port Unix applications
then the choice is obvious.

Date: 15 January 1985 16:54-EST
From: Daniel Weise <DANIEL @ MIT-MC>
Subject:  this is a test
To: INFO-GNU @ MIT-MC

Please ignore.

Received: from Burger.ms by ArpaGateway.ms ; 15 JAN 85 12:09:11 PST
Sender: "Daniel S. Conde".osbunorth@XEROX.ARPA
Date: 15 Jan 85 12:08:45 PST (Tuesday)
Subject: Re: idea for Gnu shell
From: Conde.osbunorth@XEROX.ARPA
To: root%bostonu.csnet@CSNET-RELAY.ARPA
cc: Conde.osbunorth@XEROX.ARPA, Velu@MARYLAND.ARPA, INFO-GNU@MIT-MC.ARPA
In-Reply-to: root%bostonu.csnet%csnet-relay:ARPA's message of 15 Jan 85
 10:54:37 PST (Tuesday)


Barry,
You are  correct about violating the law of least astonishment.
Originally, I though that I could make the case independency  an option,
but I do not know what to do when you turn the option off, or if you
restore a TAPE, say, with multiple matches.

At least on my system, when I have a file: "README",
and I try to create/store another file "readme", it will overwrite the
"README".

When I brought this matter up before, people tell me that "I name ALL my
files with lower case only, so there is no problem". I belive that's a
non answer though...

Possible solutions are (when you have multiple matches)
1) Treat multiple matches as a "wild card match" README = readme README
ReadMe (not good...hard to understand)
2) Take the given argument and look for the EXACT match? README =
README, and README != readme. (not easy to understand, but
acceptable...)
3) Make it work for ls, ed, and other tools that expect user input
(rather limited).

The matter of backward compatibility makes this hard...

Dan Conde


Received: from bostonu by csnet-relay.csnet id a005333; 15 Jan 85 13:13 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA24469; Tue, 15 Jan 85 12:34:05 est
Date: Tue, 15 Jan 85 12:34:05 est
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: Conde.osbunorth@XEROX.ARPA, Velu@MARYLAND.ARPA
Subject: Re:  idea for Gnu shell
Cc: INFO-GNU@MIT-MC.ARPA

	I disagree without a special match-meta character
	(are there any left?) UNIX is a full case system
	you are only thinking of ls or maybe ed, whatabout
	-* rm *- !!! This violates the law of least astonishment.
	Does this mean that 'rm readme' deletes all files
	readme README ReadMe etc?? I hope not, I think
	it would be easier to explain to a naive user
	that upper/lower case must be obeyed, that's not
	a hard concept. As for a special meta-matching,
	[Rr][Ee][Aa][Dd][Mm][Ee] exists although I admit
	it would be annoying if done often, a short-hand
	notation for that might be useful.

			-Barry Shein


Received: from Burger.ms by ArpaGateway.ms ; 15 JAN 85 10:25:35 PST
Sender: "Daniel S. Conde".osbunorth@XEROX.ARPA
Date: 15 Jan 85 10:08:33 PST (Tuesday)
Subject: TERMCAP, mkmf, print
From: Conde.osbunorth@XEROX.ARPA
To: INFO-GNU@MIT-MC.ARPA


While looking at the tasks lists, I've noticed that
1) ul' is listed in as a needed utility. However, ul uses TERMCAP, which
is in turn is set by TSET. I do not know if you plan to use the TERMCAP
environment variable, but if not, the ul' is not needed. If you plan to
put that stuff in the kernel, then perhaps another type of perusal
fileter could be written

2) mkmf. I believe that Peter Nicklin wrote mkmf at Berkeley (he's gone
now) as a part of his spms (sp?) program management program. Is so, then
it is probably available. If not, I have a friend who wrote the original
version which I think Peter based his thing on. 

3) Print. Print is (at least on the 4.2 system) just a shell script that
goes like
----
#! /bin/csh -f
#
#       @(#)print.sh    4.2     (Berkeley)      83/01/13
#
lpr -p $*

------

Received: from Burger.ms by ArpaGateway.ms ; 15 JAN 85 10:24:34 PST
Sender: "Daniel S. Conde".osbunorth@XEROX.ARPA
Date: 15 Jan 85 10:04:30 PST (Tuesday)
Subject: Re: idea for Gnu shell
From: Conde.osbunorth@XEROX.ARPA
To: velu@LL-XN.ARPA
cc: INFO-GNU@MIT-MC.ARPA
In-Reply-to: velu%LL-XN:ARPA's message of 14 Jan 85 19:46:46 PST
 (Monday)



I like the "compiled" shell scripts idea. This is basically like what
some BASIC interpreters do, right? Anything so speed! 

(However, I do not know if a run time symbolic substitution of keywords
is possible. For example, if you have a variable used in place of a
keyword, or a label, and set it to something at run time, what will
happen?)

I have some wild ideas from the Cedar exec.
1) If some commands are "pre registered" with the shell, doing this will
be useful:
&7 run?
Run 	load and stat the name programs.
The "?" is the trigger. This is a part of the more general help
facility, right?

2) this is kind of hard..but
&8 run watcch
watcch -> watch
A DWIM facility, is you could do some pattern matching for failed
programs.

Other stuff.

3) In Gosling's EMACS, I've used its SHELL feature so I could edit the
command line before dispatching it. Will that happen?

Finally, I remember that Bill Joy complained that shell scripts are too
expensive for normal use since you need a new shell invoked each time.
For example, the (bletch) IBM EXEC facility is fast enough so that
people all over write SCRIPTS. Could shell scripts be more "light
weight"?

Also, I don't know about the "TSH" (sp?), but have heard RAVES about the
Korn Shell. It's apparently a Bell internal shell, but allows editing
and such. Does anyone know the details?

Dan Conde
conde.pa@Xerox.ARPA

Received: from Burger.ms by ArpaGateway.ms ; 15 JAN 85 09:58:34 PST
Sender: "Daniel S. Conde".osbunorth@XEROX.ARPA
Date: 15 Jan 85 09:53:48 PST (Tuesday)
Subject: Chmod and GNU FS
From: Conde.osbunorth@XEROX.ARPA
To: INFO-GNU@MIT-MC.ARPA
cc: Conde.osbunorth@XEROX.ARPA


(sorry if this was sent twice)

I was thinking about "chmod" for Gnu, and noticed the "misfunctionality"
flag given for the "groups" program. Are there significant differences
between te standard unix file protection scheme and the proposed gnu
file system? This may affect how the contributors will write code for
"chmod" and anything related..

Date: 15 January 1985 04:44-EST
From: Howard D. Trachtman <HDT @ MIT-MC>
Subject:  idea for Gnu shell
To: Conde.osbunorth @ XEROX
cc: INFO-GNU @ MIT-MC, Velu @ MARYLAND
In-reply-to: Msg of 14 Jan 85 16:08:27 PST () from Conde.osbunorth at XEROX.ARPA


    Hi. I've heard that you are working in the Gnu shell, and I have an
    idea. 

    For file name matching, it would be nice to IGNORE case, but allow for
    files to be named with various cases. I.e. I could type in 
    1 % vi alongnamethatiwillnotrememberhowtotype
    but that will match the file
    2 % ls
    ALongNameThatIWillNotRememberHowToType	Foo	Bar

    3 %       
RMS, the main person behind the gnu coding effort, albeit with apparently many
appreciated assists from hackers all over, in fact previously coded what I currently
consider this Exact scheme for the MIT Lisp Machine FileSystem.  Personally, I like
it, but if unix/compat is still a concern, I'm not sure this is a good idea for GNU;
as much as I REALLY like this sort of scheme.

But because I am very much interested in information sharing and cooperation amoung
all computer communities, I would like to ask you if it is the case that this idea
has already been implemented on some particular machine/OS that you are aware, if you
could let me know which one(s) I would greatly appreciate it.

Received: by sri-tsca at Mon, 14 Jan 85 23:28:21 pst
Date: Mon, 14 Jan 85 23:28:21 pst
From: E. Howard Alt <alt@sri-tsca>
Message-Id: <8501150728.AA10534@sri-tsca>
To: velu@ll-xn
Subject: Re: idea for Gnu shell
Cc: info-gnu@mit-mc

I like the compiled shell script idea.  This dosn't really relate to
the gsh, but has anyone thought about shared libraries, shared memory,
or dynamic linking?


					Howard.

Received: by ll-xn.ARPA (4.12/4.7)
	id AA09845; Mon, 14 Jan 85 22:46:28 est
Date: Mon, 14 Jan 85 22:46:28 est
From: velu@ll-xn (Velu Sinha)
Message-Id: <8501150346.AA09845@ll-xn.ARPA>
To: conde.pa@xerox
Subject: Re:  idea for Gnu shell
Cc: Conde.osbunorth@XEROX.ARPA, INFO-GNU@MIT-MC.ARPA

Our pattern matching algorithm already employs that feature,
and many of the nsh and tsh (sp?) features. 

Hopefully, the gnu shell (gsh) will be available for beta test by 
april/may, right now we are still trying to make the interpreter 
interpret properly.

Does anyone have any "C" features that they would like added to the
csh implementation? (Ie, any "programming" changes?)

We have been considering having "compiled" shell scripts,
ones which have been compiled by pre-tokenizing them, and then
just running the interpreter on the tokens, how does this sound?

Any other ideas/features?

Thanks, Dan, for your comments, we look forward to more of the
same!

Keep those ideas coming...

					- Velu



Received: from Burger.ms by ArpaGateway.ms ; 14 JAN 85 18:28:29 PST
Sender: "Daniel S. Conde".osbunorth@XEROX.ARPA
Date: 14 Jan 85 16:08:27 PST (Monday)
Subject: idea for Gnu shell
From: Conde.osbunorth@XEROX.ARPA
To: Velu@MARYLAND.ARPA
cc: INFO-GNU@MIT-MC.ARPA, Conde.osbunorth@XEROX.ARPA


Hi. I've heard that you are working in the Gnu shell, and I have an
idea. 

For file name matching, it would be nice to IGNORE case, but allow for
files to be named with various cases. I.e. I could type in 
1 % vi alongnamethatiwillnotrememberhowtotype
but that will match the file
2 % ls
ALongNameThatIWillNotRememberHowToType	Foo	Bar

3 %       

I do not know at what level such matching could be made, but perhaps the
shell could do it, since I am mostly concerned with helping people type
in filenames.  I find it handy on the file system I use, and I think it
will make the gnu shell useful (especially with the longer file names),
and may complement the file name matching feature. What do you think?

Dan Conde
conde.pa@Xerox.ARPA

Date: 11 January 1985 03:25-EST
From: Howard D. Trachtman <HDT @ MIT-MC>
Subject:  with all the talk about jove...
To: INFO-GNU @ MIT-MC


    Date: 30 Aug 84 22:21:47-PDT (Thu)
    To: Unix-Emacs@Cmu-Cs-C.ARPA
    From: sun!gnu@Berkeley
    Subject: Re: JOVE-- who owns it?

    Jove was distributed to anybody who asked on Usenet.  It was done by
    Jonathan Payne at Lincoln-Sudbury Regional High School.  Since it was
    given away and no copyrights appear in it, it is public domain by
    default.  The author's address, if you really want to check, is:

	    Jonathan Payne
	    15 Thoreau Way
	    Sudbury, MA 01776

    (from the README file.)  I've lost his net address.

Received: by tove.ARPA (4.12/4.7)
	id AA06115; Sun, 6 Jan 85 11:43:46 est
From: Mark Weiser <mark@tove>
Message-Id: <8501061643.AA06115@tove.ARPA>
Date:  6 Jan 1985 1143-EST (Sunday)
To: "Carl C. Hewitt" <CCH@mit-mc.ARPA>
Cc: INFO-GNU@mit-mc.ARPA
In-Reply-To: Your message of 4 January 1985 05:52-EST.
             <8501060452.AA16265@maryland.ARPA>

Jonathon's Own Version of Emacs (JOVE) is an ersatz emacs that is quite
small and reasonably complete given its lack of programmability.  It
runs on most Unix systems (we run it on our pdp-11/44).  It was posted
to net.sources a long time ago.  Our maintainers here are louie@umd5
and rehmi@maryland--try them for more info.
----------
Spoken: Mark Weiser 	ARPA:	mark@maryland	Phone: +1-301-454-7817
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742


Received: by utah-cs.ARPA (4.42/4.40.1)
	id AA00956; Mon, 7 Jan 85 04:19:55 MST
Date: Mon, 7 Jan 85 04:19:55 MST
From: lepreau@utah-cs (Jay Lepreau)
Message-Id: <8501071119.AA00956@utah-cs.ARPA>
To: info-gnu@mit-mc
Subject: Re:  Emacs

I recommend 'jove' (Jonathan's Own Version of Emacs) by Jonathan Payne,
formerly of Lincoln-Sudbury H.S.  It's the best of the "small" emacs'es
I've seen.  We run it on vaxen, but it was developed to run on 11's.
Is very featureful considering it fits on an 11-- very nice.

It is public domain.

Received: by utah-cs.ARPA (4.42/4.40.1)
	id AA00956; Mon, 7 Jan 85 04:19:55 MST
Date: Mon, 7 Jan 85 04:19:55 MST
From: lepreau@utah-cs (Jay Lepreau)
Message-Id: <8501071119.AA00956@utah-cs.ARPA>
To: info-gnu@mit-mc
Subject: Re:  Emacs

I recommend 'jove' (Jonathan's Own Version of Emacs) by Jonathan Payne,
formerly of Lincoln-Sudbury H.S.  It's the best of the "small" emacs'es
I've seen.  We run it on vaxen, but it was developed to run on 11's.
Is very featureful considering it fits on an 11-- very nice.

It is public domain.

Received: by sri-tsca at Fri, 4 Jan 85 16:34:39 pst
Date: Fri, 4 Jan 85 16:34:39 pst
From: E. Howard Alt <alt@sri-tsca>
Message-Id: <8501050034.AA15905@sri-tsca>
To: CCH@MIT-MC, INFO-GNU@MIT-MC
Subject: Emacs

there is a program called elle that is a small subset of emacs... it
is pretty good. we use it here on our pdp-11/44s.  It is fairly
fast, and works in small address spaces.

						Howard.

ps send mail to klh@nic, I think it is his.

Date: 4 January 1985 05:52-EST
From: Carl C. Hewitt <CCH @ MIT-MC>
To: INFO-GNU @ MIT-MC

Hello,
	Does anyone know if there is a version of EMACS that would
run on a PDP-11/70 running V7. I know thats a tall order, but I
am hoping that it exists somewhere.. Thanx!
		-- Carl

PS. Whoops, disregard the next msg you see from me.. (All these different
    mail programs have different end-of-msg characters!)

Date: 4 January 1985 05:40-EST
From: Carl C. Hewitt <CCH @ MIT-MC>
To: INFO-GNU @ MIT-MC

  Hello,
	Does anyone know if 

Date: Thu 3 Jan 85 12:38:43-EST
From: Mark Plotnick <M.MP%MIT-EECS@MIT-MC.ARPA>
Subject: Re: New task list
To: RMS@MIT-MC
cc: INFO-GNU@MIT-MC
In-Reply-To: Message from "Richard M. Stallman <RMS @ MIT-MC>" of Wed 2 Jan 85 07:38:38-EST

dbm(3) is from V7, so it's not public domain.  Chris Torek at Maryland
sent his own implementation of it to netnews awhile ago - it's called
mdbm.  Try chris@maryland to get the most recent version.
-------

Date: 2 Jan 1985 19:10:53-EST
From: jfw at CCC
To: INFO-GNU@MIT-MC, RMS@MIT-MC
Subject: Re:  New task list

dbm(3x) from Berkeley is likely suspect, but there is a public domain
dbm library available from netnews.  If it can't be found on Eddie, then
I can copy it from Frog.

I'd like a copy of the wish list.  Is the super Emacs heavily dependant
on 4.2, or is there a hope of making it run here at CCC on 2.9?

Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.24/4.40)
	id AA09060; Wed, 2 Jan 85 12:42:58 pst
Received: by ucbernie.ARPA (4.24/4.40)
	id AA03986; Wed, 2 Jan 85 12:51:11 pst
Date: Wed, 2 Jan 85 12:51:11 pst
From: dambrosi%ucbernie@Berkeley (Bruce D'Ambrosio)
Message-Id: <8501022051.AA03986@ucbernie.ARPA>
To: INFO-GNU@MIT-MC, RMS@MIT-MC
Subject: Re:  New task list

I am interested in the utility list.  Also, I would be happy to 
help test the new EMACS. I have access to 4.2, 4.1, and a variety of
other boxes running flavors of C (e.g. - Pyramid

Date: 2 January 1985 07:30-EST
From: Richard M. Stallman <RMS @ MIT-MC>
Subject:  New task list
To: INFO-GNU @ MIT-MC

I now have a list giving the status of obtaining or
duplicating all the utilities of 4.2,
and also mentioning about 50 utilities that are wanted most.
I will send you a copy if you ask.

I have now a free super Emacs, with a real Lisp interpreter.
It should be ready to distribute in a month or two,
but I could use a few people to help me test it
any time.  It currently runs on 4.2.

Does any one know whether the ctags(1) in 4.2 is free
for GNU to use?  What about dbm(3X)?

Received: from MIT-MC by MIT-OZ via Chaosnet; 21 Dec 84 02:58-EST
Date: 21 December 1984 02:48-EST
From: Howard D. Trachtman <HDT @ MIT-MC>
To: info-gnu @ MIT-OZ

Has a public domain history mechanism been implemented yet?

Received: from dartmouth by csnet-relay.csnet id ab20350; 9 Dec 84 2:36 EST
Received: by dartmouth.CSNET (4.12/1.16)
	id AA12053; Sat, 8 Dec 84 19:50:26 est
Date: Sat, 8 Dec 84 19:50:26 est
From: Mike Morton <mike%dartmouth.csnet@csnet-relay.arpa>
To: RMS%MIT-OZ%mit-mc.arpa@csnet-relay.arpa, 
    info-gnu%mit-mc.arpa@csnet-relay.arpa

Richard --
     I just got back to my old Unix system at Dartmouth and found I
seem to be on a mailing list for GNU info.  Could you take me off it
for the moment?  I have a strong long-term interest for GNU and other
freeware projects in the long term, but am too busy and won't have regular
access to a Usenet node for a while to come.  I DO have your paper mail
address and phone (from our brief Usenet correspondence this year).  I'll
keep in touch, but for now I won't be seeing stuff sent to this node.
     Thanks,
 -- Mike Morton


Received: from dartmouth by csnet-relay.csnet id ae08457; 6 Dec 84 19:38 EST
Received: by dartmouth.CSNET (4.12/1.16)
	id AA06362; Thu, 6 Dec 84 17:25:54 est
Received: by dalcs.UUCP (4.12/4.7)
	id AA00816; Thu, 6 Dec 84 15:00:42 ast
From: Reg Hody <hody%dalcs%dartmouth.csnet@csnet-relay.arpa>
Date:  6 Dec 1984 1500-AST (Thursday)
Message-Id: <788.3.471207634@dalcs>
To: mit-mc!dartvax!info-gnu@DARTMOUTH.CSNET
Subject: Questions about GNU.
Fcc: mailout

Dear Sir/Madam/RMS;
	Could I get further information on GNU. Such as 1)present status,
2) unallocated tasks, 3) mailing list? If there is a mailing list,
I would like to be added (dalcs!hody@dartmouth).

				reg

Reg Hody, Dalhousie University, Halifax, Nova Scotia. B3H 4H8 (902-424-6501)
{allegra,decvax,decwrl,floyd,ihnp4}!utcsrgv!dalcs!hody
or...	dalcs!hody@dartmouth


Date: 6 Dec 84 12:33:36 PST (Thu)
From: Hans Muller <hans@aids-unix>
Subject: status
To: info-gnu@mit-mc.arpa, @, aids-unix@aids-unix


What is the status GNU? Is there a repository of code/documentation
somewhere? I had originally planned to contribute to GNU development
however I really haven't had even close to enough free time. Recently
I have been attempting to port chunks of the Unix environment to a 
image processing workstation, the cpu is a 68K. I would be willing
to experiment with the GNU versions of Unix tools if they are available.


Hans Muller
hans@aids-unix

Received: from buffalo by csnet-relay.csnet id ae01296; 5 Dec 84 18:15 EST
Received: by gort.SUNYAB (4.12/4.7)
	id AA09872; Wed, 5 Dec 84 13:26:00 est
Date: Wed, 5 Dec 84 13:26:00 est
From: "James A. Lahren" <lahren%buffalo.csnet@csnet-relay.arpa>
To: RMS%MIT-OZ <@csnet-relay.arpa:RMS%MIT-OZ@mit-mc.ARPA>, 
    info-gnu@mit-mc.ARPA
Subject: matching and searching..

	From RMS%mit-oz@MIT-MC@csnet-relay Thu Nov 29 13:15:46 1984
	Received: by gort.SUNYAB (4.12/4.7)
		id AA07776; Thu, 29 Nov 84 12:56:08 est
	Message-Id: <8411291756.AA07776@gort.SUNYAB>
	Received: from mit-mc.arpa by csnet-relay.arpa id a002924; 29 Nov 84 3:47 EST
	Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 29 Nov 84 03:40-EST
	Date: Thursday, 29 November 1984, 03:41-EST
	From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC@csnet-relay>
	To: info-gnu@MIT-MC
	Received: from CSNet-Relay by buffalo; 29 Nov 84 11:52:29-EST (Thu)
	Status: RO
	
	I just wrote a very extended regex library, which allows
	things like "the \(ba\(na\)*\|orange\) peel" as patterns
	and has other interesting features for controlling matching
	and searching.  I'll send details if you are interested.
	
	
***************

  i would definitely be interested in having
  a copy of what you are talking about....

                                     thanx,

                                     -- jim lahrne
                                            (lahren)   stupid adm3a,
                                                       volker craig
                                                       typo...


Received: from MIT-LISPM-4 by MIT-OZ via Chaosnet; 29 Nov 84 03:40-EST
Date: Thursday, 29 November 1984, 03:41-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
To: info-gnu at MIT-MC

I just wrote a very extended regex library, which allows
things like "the \(ba\(na\)*\|orange\) peel" as patterns
and has other interesting features for controlling matching
and searching.  I'll send details if you are interested.

Received: by maryland.ARPA (4.12/4.7)
	id AA28171; Tue, 11 Sep 84 12:45:49 edt
Date: Tue, 11 Sep 84 12:45:49 edt
From: mark@maryland (Mark Weiser)
Message-Id: <8409111645.AA28171@maryland.ARPA>
To: cbosgd!mark@ucb-vax.ARPA, info-gnu@mit-mc.ARPA
Subject: Re:  regular expressions

A slight other difference is that -i to grep means ignore
case, but there is no such option to egrep.

Received: by UCB-VAX.ARPA (4.40/4.38)
	id AA03583; Mon, 10 Sep 84 19:46:50 PDT
Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/3.7)
	id AA06062; Mon, 10 Sep 84 21:44:38 edt
Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14)
	id AA10611; Mon, 10 Sep 84 21:45:04 edt
Date: Mon, 10 Sep 84 21:45:04 edt
From: cbosgd!mark@Berkeley (Mark Horton)
Message-Id: <8409110145.AA10611@cbpavo.cbosgd.ATT.UUCP>
To: info-gnu@mit-mc.arpa
Subject: Re:  regular expressions

The only difference between ex(1) r.e.'s and ed(1) r.e.'s is the
\< and \> word markers.  Being upward compatible with ex is an
obvious given, almost.

The catch is that egrep's r.e.'s are slightly different.  In particular,
more characters are reserved in egrep (they need \ to be interpreted
as text), in particular, these are + ? | ( ) which mean "1 or more of
the preceding", "0 or 1 of the preceding", "or", "start group" and
"end group" (that is, parens group things like you expect).  Precedence
in egrep is [], then *?+, then concat, then | and newline.

Something which was just like egrep (e.g. very fast) but understands
\< and \> and -w would be wonderful.  Perhaps if argv[0][0] is 'g'
then +?|() should not be reserved, for full compatibility.

	Mark

P.S. A useful extension would be to show a few lines of context in
each direction, under some option (not default).

Date: Mon 10 Sep 84 13:09:25-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: regular expressions
To: info-gnu@MIT-MC

The 4.2 manual does contain strong hints that the
regular expressions that `grep' handles are more
general than the ones that `ed' handles.  `grep'
is said to be like `ex'; `ed' is documented but `ex' is not.
For example, there appears to be a \<...\> construct
that `grep' handles but that `ed' does not document
and maybe does not support.

I would like to straighten out this confusion in the GNU
versions of this software, but first I want to know all
the things I should try to be upward compatible with.
-------

Received: by UCB-VAX.ARPA (4.24/4.33)
	id AA15110; Mon, 10 Sep 84 00:05:46 pdt
Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/3.7)
	id AA07442; Mon, 10 Sep 84 00:41:16 edt
Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14)
	id AA09751; Mon, 10 Sep 84 00:41:52 edt
Date: Mon, 10 Sep 84 00:41:52 edt
From: cbosgd!mark@Berkeley (Mark Horton)
Message-Id: <8409100441.AA09751@cbpavo.cbosgd.ATT.UUCP>
To: info-gnu@mit-mc.ARPA
Subject: Re:  What exactly can grep handle in a pattern?

egrep is faster than either grep or fgrep, so it has the best
algorithm.  It builds an FSM from the regular expression and
then interprets the FSM as incoming characters come in.  Takes
longer to start up but runs like lightning.

For documentation of grep r.e.'s see ed(1), add \< and \> if
you mean the Berkeley grep.  These are different from egrep.
(The \< and \> match the null string at the beginning and
end of a word, respectively, so
	grep '\<foo\>' files
or the equivalent
	grep -w foo files
finds "foo" as a whole word but won't find foobar.

	Mark

Received: from CORNELL-GVAX.ARPA (gvax) by CORNELL.ARPA (4.30/4.30)
	id AA01034; Sun, 9 Sep 84 22:06:26 edt
Date: Sun, 9 Sep 84 22:01:04 edt
From: gvax.rej@Cornell.ARPA (Ralph Johnson)
Message-Id: <8409100201.AA01780@CORNELL-GVAX.ARPA>
Received: by CORNELL-GVAX.ARPA (4.30/4.30)
	id AA01780; Sun, 9 Sep 84 22:01:04 edt
To: RMS%MIT-OZ@mit-mc.ARPA, info-gnu@mit-mc.ARPA
Subject: Re:  What exactly can grep handle in a pattern?

In my documentation (4.1BSD) the description of regular expressions
is in the manual page for ed (the only reason I look at that page).
Besides being used in the editors and in grep, the regular expressions
are used in sed and in awk.  There are a pair of functions (re_comp
and re_exec, found under REGEX(3) in the manual) that implement regular
expressions.  I do not know if the editors or grep call these functions,
but I know sed does not, as sed makes a minor addition to the regular
expressions allowed.  However, sed does reuse the source to these
functions.  I assume that all these programs use essentially the same
code.

I think that I have seen some public domain versions of the regular
expression functions.  Since you will need to write these functions
in order to have a Unix compatible library, it might be a good idea
to write (or borrow) these functions once and make regular expressions
be the same for all programs.  Perhaps the DEC people know about the
public domain version of the regular expression routines?

Date: 9 Sep 1984 20:36:36-EDT
From: jfw at mit-ccc
To: RMS@mit-oz@MIT-MC.ARPA, info-gnu@mit-mc
Subject: Re:  What exactly can grep handle in a pattern?
Cc: jfw@mit-ccc

Quoting from the Version 7 manual*,

Grep patterns are limited regular expressions in the style of ed(1)**

	>1. Any character except a special character matches itself.
	    Special characters are the regular expression delimiter
	    (either ? or /) plus \[. and sometimes ^*$.
	 2. A . matches any character.
	 3. A \ followed by any character except a digit or () matches
	    that character.
	 4. A nonempty string s bracketed [s] (or [^s]) matches any
	    character in (or not in) s.  In s, \ has no special meaning
	    and ] may only appear as the first letter.  A substring a-b
	    with a and b in ascending ASCII order, stands for the inclusive
	    range of ASCII characters.
	 5. A regular expression of form 1-4 followed by * matches a sequence
	    of 0 or more matches of the regular expression.
	 6. A regular expression, x, of form 1-8, bracketed \( x \)
	    matches what x matches.
	 7. A \ followed by a digit n matches a copy of the string that the
	    bracketed regular expression beginning with the nth \( matched.
	 8. A regular expression of form 1-8, x, followed by a regular
	    expression of form 1-7, y, matches a match for x followed by
	    a match for y, with the x match being as long as possible while
	    still permitting a y match.
	 9. A regular expression of form 1-8 preceeded by ^ (or followed
	    by $), is constrained to matches that begin at the left (or
	    end at the right) end of a line.
	10. A regular expression of form 1-9 picks out the longest among the
	    leftmost matches in a line.
	11. An empty regular expression stands for a copy of the last
	    regular expression encountered.

SYSTEM III/V UNIX (and Berkeley BrainSoftwareDamage) have a subroutine to
parse and perform these expressions.

While this information is available in manuals (somewhere), perhaps having
it in your mailbox will ease life a little.

EGREP:  I don't know which algorithm it uses, but I seem to recall that
somewhere in ancient documentation is the mention that its algorithm was the
topic of a paper.  At any rate, regular expressions certainly aren't very
hard to devise algorithms for.  Tomorrow I can look up a paper on a "fast
regular expression" algorithm, which happens to be used at CRDS (I think I
can look up the paper without anyone's being upset there).

* Seems like the more people "improve" UNIX, the shittier it gets.

** And that goes double for any documentation out of Berkeley or Bell Labs!

Sigh.  Let's hear it for Version 6!

Received: from MIT-LISPM-24 by MIT-OZ via Chaosnet; 9 Sep 84 14:22-EDT
Date: Sunday, 9 September 1984, 14:26-EDT
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: What exactly can grep handle in a pattern?
To: info-gnu at MIT-MC

The manual says "see ex(1)" but under ex it says only to
see some other document.

Does anyone know anything about the algorithm that egrep uses,
or any good algorithm to use?

Received: from MIT-LISPM-24 by MIT-OZ via Chaosnet; 7 Sep 84 20:31-EDT
Date: Friday, 7 September 1984, 20:34-EDT
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
To: info-gnu at MIT-MC

I've just completed a `sort' which is faster than the Unix one
and does not truncate lines of whatever length,
and a `fold' that does not mess up underscores or other overprinting
and is not confused by tabs.

Date: Sun 2 Sep 84 21:20:55-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Re: Which Emacs for GNU?
To: sjk@SRI-SPAM.ARPA
cc: info-gnu@MIT-MC
In-Reply-To: Message from "Scott J. Kramer <sjk@sri-spam>" of Sun 2 Sep 84 17:42:00-EDT

Fen says he was given permission to redistribute Gosling's Emacs,
and he has given me (and anyone else) permission too.
Since Unipress seems to have decided not to sue Megatest,
there is nothing they can do to me, or to any of you.
That's enough to satisfy me, since I don't believe in
software ownership.

It runs Mlisp.

I personally have not used it yet.  The vax it is up on
isn't the one I use.  I may do something about it soon, though.
I have not got a tape from Eric yet.
-------

Received: by sri-spam.ARPA (4.22/4.16)
	id AA06293; Sun, 2 Sep 84 14:42:18 pdt
From: Scott J. Kramer <sjk@sri-spam>
Message-Id: <8409022142.AA06293@sri-spam.ARPA>
Reply-To: sjk@sri-spam
Date:  2 Sep 1984 1442-PDT (Sunday)
To: info-gnu@mit-mc
Subject: Which Emacs for GNU?

    Date: Saturday, 4 August 1984, 19:24-EDT
    From: "Richard M. Stallman" <RMS@MIT-PREP>
    To: info-gnu@mc

		    .	.	.

    A copy of the free formerly-Gosling's Emacs just arrived from
    megatest!fen@shasta.arpa, and it has been put up on a vax here.
    Soon some upgrades written by Eric the Flute of Rabbit Software
    should arrive on a tape, along with `sed'.

Has anyone had a chance to use this editor yet?  If it's a Gosling's
Emacs mutant, is there any proprietary code involved?  Does it run
MLisp or any other extension language?

    Date: 30 Aug 84 22:21:47-PDT (Thu)
    To: Unix-Emacs@Cmu-Cs-C.ARPA
    From: sun!gnu@Berkeley
    Subject: Re: JOVE-- who owns it?

    Jove was distributed to anybody who asked on Usenet.  It was done by
    Jonathan Payne at Lincoln-Sudbury Regional High School.  Since it was
    given away and no copyrights appear in it, it is public domain by
    default.  The author's address, if you really want to check, is:

	    Jonathan Payne
	    15 Thoreau Way
	    Sudbury, MA 01776

    (from the README file.)  I've lost his net address.


From a user standpoint (I haven't compared sources yet) JOVE looks
alot like Gosling's Emacs, minus MLisp.  Maybe it can be made part
of GNU, altho' some versions of Emacs with an extension language is
probably preferred.

scott

Received: by sri-spam.ARPA (4.22/4.16)
	id AA02738; Sun, 2 Sep 84 01:53:44 pdt
Date: Sun, 2 Sep 84 01:53:44 pdt
From: Scott J. Kramer <sjk@sri-spam>
Message-Id: <8409020853.AA02738@sri-spam.ARPA>
Reply-To: sjk@sri-spam
To: godot!bruce@cca-unix
Subject: "csh" line editor
Cc: info-gnu@mit-mc.ARPA

We run a version of the C-shell here which has an emacs-like line editor.
I don't know if any of it is in public domain, however.  Here's a note
about the authors at the end of the manual page:

AUTHORS
     Ted Anderson originally coded the line editor in PDP11
     assembly language for another purpose. Steven Correll
     recoded it	in Pascal and modified the C shell.  Earl Cohen
     re-wrote it all in	C and merged it	into the C-shell history
     mechanism.

Is anyone interested in getting more details on this shell?

scott

Date: 30 Aug 84 10:51:20 PDT (Thu)
From: Andy Cromarty <andy@aids-unix>
Subject: Re:  `sc' program question
To: RMS@MIT-OZ, @, MIT-MC@aids-unix, info-gnu@MIT-MC

According to our copy of the source (sc.c, in particular), sc was written
by James Gosling in Sept 1982.

					asc

Received: by maryland.ARPA (4.12/4.7)
	id AA29779; Thu, 30 Aug 84 00:17:25 edt
Date: Thu, 30 Aug 84 00:17:25 edt
From: mark@maryland (Mark Weiser)
Message-Id: <8408300417.AA29779@maryland.ARPA>
To: RMS%MIT-OZ@mit-mc.ARPA, info-gnu@mit-mc.ARPA
Subject: Re:  `sc' program question

If you mean 'sc' the visicalc clone, it was written by James Gosling
and is public domain (officially announced as so by him, as distinct
from his Emacs.  You must have gotten to him, Richard!)

We have been doing minor improvements to sc at maryland and also
will share.
-------------------
Spoken: Mark Weiser 	ARPA:	mark@maryland
CSNet:	mark@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!mark

Received: from MIT-LISPM-24 by MIT-OZ via Chaosnet; 29 Aug 84 18:39-EDT
Date: Wednesday, 29 August 1984, 18:41-EDT
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: `sc' program question
To: info-gnu at MIT-MC

Does anybody know who wrote the `sc' program that comes from Berkeley?

Received: by maryland.ARPA (4.12/4.7)
	id AA13646; Wed, 29 Aug 84 10:39:25 edt
Date: Wed, 29 Aug 84 10:39:25 edt
From: velu@maryland (  )
Message-Id: <8408291439.AA13646@maryland.ARPA>
To: godot!bruce@mit-eddie, mit-eddie!velu@maryland.ARPA
Cc: info-gnu@mit-mc.ARPA


Date: Tue 28 Aug 84 18:41:37-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
To: info-gnu@MIT-MC

I just got back from England, where I wrote the utilities
dc, od, look, rev, strings, split, sleep.
I also wrote ar, and was in the middle of making it do
the work of ranlib automatically when the vax went down.
I'll probably finish ar as soon as a tape of it arrives.

Now that I've written dc, it would not be very hard for
someone else to write bc.  Anyone interested?
-------

Received: by cca-unix.ARPA (4.12/4.7)
	id AA12688; Tue, 28 Aug 84 17:56:56 edt
Message-Id: <8408282156.AA12688@cca-unix.ARPA>
Received: by godot id AA07430; Tue, 28 Aug 84 15:26:42 edt
From: Bruce Nemnich <godot!bruce@cca-unix>
Date: 28 Aug 1984 1526-EDT (Tuesday)
To: mit-eddie!velu@maryland.ARPA (  )
Cc: info-gnu@mit-mc.ARPA
In-Reply-To: Your message of Tue, 28 Aug 84 11:21:58 edt.
             <8408281521.AA20881@maryland.ARPA>


I would like to see command line editing using an emacs subset,
including a kill ring to which completed commands go (to be able to yank
previous commands).  I use this on multics (and lispms, of course) and
it is invaluable.

--Bruce Nemnich, Thinking Machines Corporation, Cambridge, MA
  {astrovax,cca,harvard,ihnp4,ima,mit-eddie,...}!godot!bruce, BJN@MIT-MC.ARPA

Received: by maryland.ARPA (4.12/4.7)
	id AA20881; Tue, 28 Aug 84 11:21:58 edt
Date: Tue, 28 Aug 84 11:21:58 edt
From: velu@maryland (  )
Message-Id: <8408281521.AA20881@maryland.ARPA>
To: info-gnu@mit-mc


Hello! I am Velu Sinha, and have been worrying about the GNU Shell.
(I am physically somewhere between Maryland and Boston, at the moment closer
to Maryland...)

At the moment, the GNU Shell task has been broken into between 4 and 8
major sections. Currently, augart%prep@mc, eli@mc, and I are the major
conspirators. We do need more help, so if any thing here sounds interesting,
please send me a note...

GNU Shell Overview

The GNU Shell will have a command reader, a command/filename completer,
a history mechanism, shell variable subsitution mechanism, a C syntax
handler, a input/output redirection (and pipe-ing) mechanism, and, of
course, the exec mechanism. Some of the "neat-o" features which we hope to
implement are:
	command/filename completeion
	dettach, attach facility
	and modular systems for history, shell scripts, etc... which
	    will allow all programs to call library functions for
	    history handling, etc...

If you know of any other features (that do not already exist in the CSH)
which you think would be nce, please post them to info-gnu for discussion.

If anyone would like more detail to the structure of these mechanisms,
please let me know. 

						- Velu

Remember: Hackers are needed very badly to start writing up (and thinking
up) some of the ideas which we have come up with... 


Date: Saturday, 4 August 1984, 19:24-EDT
From: Richard M. Stallman <RMS at MIT-PREP>
To: info-gnu at mc

I just dashed off a `nm' and a `size', using pieces of `ld'.
On Monday I go to England, where I may make the C compiler
generate code for a Norsk Data ND500, or maybe not.
I'm returning at the end of the month.

I have completely given up on running the compiler on the
TI NU machine under its current nonpaging version of Unix.
This means that I can't thoroughly test 68000 code generation;
it is likely to have 4 or 5 bugs left.  I hope that I will
get a better 68000 Unix to test it on someday.  Meanwhile,
I see that Livermore has made progress on the Fortran front end.

Steve Augart expects soon to get a basic C preprocessor from Martin Minow,
and add to it the missing things such as #if.

I have mailed a letter to the ANSII C standardization committee
making a couple of suggestions and asking for permission to use
their draft standard for documentation of C.  I'm pretty sure
we will be able to do so once the standard comes out; I'm hoping
they will be able to let me do this sooner.

A copy of the free formerly-Gosling's Emacs just arrived from
megatest!fen@shasta.arpa, and it has been put up on a vax here.
Soon some upgrades written by Eric the Flute of Rabbit Software
should arrive on a tape, along with `sed'.

Received: by harvard.ARPA (4.12/4.27)
	id AA00957; Thu, 19 Jul 84 18:33:33 edt
Date: Thu, 19 Jul 84 18:33:33 edt
From: hscvax!augart@harvard.ARPA
Message-Id: <8407192233.AA00957@harvard.ARPA>
Subject: the last line of the last letter
To: INFO-GNU@MIT-MC.ARPA

should have read "drop me a line at the address below." Sorry.
S. Augart


Received: by harvard.ARPA (4.12/4.27)
	id AA00944; Thu, 19 Jul 84 18:33:19 edt
Date: Thu, 19 Jul 84 18:33:19 edt
From: hscvax!augart@harvard.ARPA
Message-Id: <8407192233.AA00944@harvard.ARPA>
Subject: C pre-processor
To: INFO-GNU@MIT-MC.ARPA

RMS has asked me to tell you what I'm doing, so here I go...
I'm writing the  C preprocessor.  I work sporadically, so it won't be done
for a couple of weeks yet. If anybody has written something useful in
this (it would be nice to have routines that manage the association
table between the macro name and the defined macro) then please drop
---------

Steven Augart
UUCP: {harvard,wjh12}!hscvax!augart_b
ARPA: hscvax!augart_b@harvard
BITNET: augart_b%HARVUNXU
(617) 646-1588


Received: by UCB-VAX.ARPA (4.28/4.31)
	id AA10271; Mon, 16 Jul 84 23:35:25 pdt
Received: by amd.UUCP (4.12/4.7)
	id AA01015; Mon, 16 Jul 84 20:04:44 pdt
Date: Mon, 16 Jul 84 20:04:44 pdt
From: amd!phil@Berkeley (Phil Ngai)
Message-Id: <8407170304.AA01015@amd.UUCP>
To: info-gnu@mit-mc.ARPA
Subject: delete amd70

please delete all addresses with amd70 on them. that machine
no longer exists.

	Phil Ngai
	AMD system manager and former amd70 manager

Date: Sun 15 Jul 84 18:42:33-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Re: idea for a public domain vi editor
To: cbosgd!mark@UCB-VAX.ARPA, info-gnu@MIT-MC
In-Reply-To: Message from "cbosgd!mark@Berkeley (Mark Horton)" of Sun 15 Jul 84 17:07:26-EDT

Eric Raymond has written a free `sed' for me, but has not sent it to me yet.
It seems likely that that would contain a useful part of the
things needed to fix up `vi'.  I will press him to send it to me soon.
Is anyone interested in hacking this?
-------

Received: by UCB-VAX.ARPA (4.28/4.31)
	id AA02134; Sun, 15 Jul 84 13:16:10 pdt
Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/3.7)
	id AA20848; Sun, 15 Jul 84 15:34:12 edt
Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14)
	id AA03038; Sun, 15 Jul 84 15:32:38 edt
Date: Sun, 15 Jul 84 15:32:38 edt
From: cbosgd!mark@Berkeley (Mark Horton)
Message-Id: <8407151932.AA03038@cbpavo.cbosgd.ATT.UUCP>
To: info-gnu@mit-mc.ARPA
Subject: idea for a public domain vi editor

I realize a lot of the people on this mailing list are hopelessly
addicted to EMACS, but I had an idea and wanted to pass it along.

Most of the code in vi is in the public domain.  However, about 10%
of the code (at most) is directly derived from the V6 "ed" command.
This code does buffer management, file input/output, and parsing of
ex commands.  It occurs to me that there is an ed style editor in
the Software Tools book, which does essentially all this same stuff,
and is in the public domain.  It ought to be possible to rip out the
ed code from vi and replace it with code based on this Software Tools
editor, resulting in a completely public domain vi.

In particular, note that all code in any vi source file whose name
starts with "ex_v" is 100% public domain - this includes all the
screen handling code (even ex_put.c and ex_tty.c) and all the vi
commands themselves.  But they do all use the underlying buffer
manager, which is not very different from the one in ed.

If someone wants to do this work, I'll be happy to cooperate by
pointing out which functions are and are not PD, explaining how
things work, and answering questions.  As a starter, running ctags
on ed.c will provide a list of functions that are in ed; these
functions with the same names in vi contain some V6 ed code.

	Mark Horton
	cbosgd!mark
	mark@Berkeley.ARPA

Received: from MIT-LISPM-8 by MIT-OZ via Chaosnet; 15 Jul 84 13:22-EDT
Date: Sunday, 15 July 1984, 13:22-EDT
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: linker implemented
To: info-gnu at MIT-MC

I've finished the linker (`ld') and its documentation.
I think it does everything the 4.2 manual says it should do.

I also wrote a complete, correct document for a.out format.
If anyone ever wants to know what the Unix manual doesn't say,
this should help.

Received: from MIT-LISPM-1 by MIT-OZ via Chaosnet; 11 Jul 84 09:12-EDT
Date: Wednesday, 11 July 1984, 09:12-EDT
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Format of data made by ranlib needed urgently
To: info-gnu at MIT-MC

What is the format of the __.SYMDEF archive subfile that ranlib makes?

Being unable to continue getting the compiler to run on the 68000
due to a subtle problem in the 68000 .o files that nobody can find,
I decided to write a new 'ld' so that I can get both parts of the
situation under control.

I have made a lot of progress on writing the new 'ld', but I find
that libc was processed with ranlib and that a sequential pass
through it really does not get all the subfiles that are needed.
It seems clear that the 'ld' cannot be useful if it ignores the
__.SYMDEF file, but the format is not in the manual.

Please help me if you can.

Received: from MIT-LISPM-2 by MIT-OZ via Chaosnet; 31 May 84 02:08-EDT
Date: Thursday, 31 May 1984, 02:09-EDT
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
To: info-gnu%MIT-OZ@MIT-MC.ARPA

The C compiler has compiled itself correctly, for the Vax.

It produces code a little better than the standard Vax compiler,
and does not require (or use) register declarations.
It currently takes slightly longer to run, but it should be
faster when I am done.

Date: Wed 9 May 84 23:26:29-PDT
From: Scott M. Hinnrichs <SMH@SRI-KL.ARPA>
Subject: Re:  How many printfs could a printf printf if a printf could printf printf
To: rmc@CCA-UNIX.ARPA, root%bostonu.csnet@CSNET-RELAY.ARPA
cc: info-gnu@MIT-MC.ARPA
In-Reply-To: Message from "rmc@cca-unix (Mark Chilenskas)" of Mon 7 May 84 09:45:09-PDT

	Looks like the predictions that the GNU kernel and associated
utilities will end up being "NOT UNIX", are coming true.

	A great artist once told me that if you are going to steal
an idea and copy it, make it a DIRECT lift.  Otherwise, you are only
fooling yourself.

	The precept that GNU is based on is good.  Make a Public
Domain UNIX.  Follow that precept and we can all win by getting a
complete Public Domain UNIX.

	Please.

	Scott M. Hinnrichs
	SRI International
-------

Date: Tue 8 May 84 00:37:58-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: printf
To: info-gnu@MIT-MC

I am not going to put printf in the kernel.
I would like to have the ability to share it (and all of stdio)
between programs as part of the user address space.  I will do this
if it is not too hard.
-------

Date:  7-May-84 22:41:16-EDT
From: jpm@BNL
Subject: printf in the kernel
To: Info-Gnu@MIT-MC

The problem I see with adding printf to the kernel is that
once you add printf you have to add the standard I/O library.
I'm not sure if this is a good thing. I would like to see
something like printf available as a system call, but only if
it worked with low level files (i.e. accessed using read and
write). There have been many times I needed formatted output
in a small program, but the stdio that ended up linked on
turned the small program into a monster. In the real world
people use Unix on 15 meg and smaller hard disks and anything
that can be done to reduce the size of program files is
appreciated.

John McNamee		jpm@Bnl.Arpa

Received: From umcp-cs.csnet by csnet-relay;  7 May 84 13:19 EDT
Date:     7 May 84 13:10:37 EDT  (Mon)
From:     James O'Toole <james@umcp-cs.arpa>
Subject:  Re: shared libraries
To:       info-gnu@mit-mc.arpa

Don't.  See if you can make unix *smaller*, not bigger.  Providing a minimal
set of system primitives is very important to good operating system design.
A system primitive should be something that the OS must provide because
it is impossible for the user process to do without being able to violate
the system in some way (other procs memory, file system, etc.)

  --Jim

Received: From bostonu.csnet by csnet-relay;  7 May 84 13:12 EDT
Received: by csvaxa.ARPA (4.12/4.7)
	id AA12939; Mon, 7 May 84 11:21:44 edt
Date: Mon, 7 May 84 11:21:44 edt
From: God <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8405071521.AA12939@csvaxa.ARPA>
To: M.MP%MIT-EECS%mit-mc.arpa@csnet-relay.arpa, 
    root%bostonu.csnet@csnet-relay.arpa
Subject: Re: Standards Fans...
Cc: info-gnu%mit-mc.arpa@csnet-relay.arpa


	I stand corrected to the extent that the 4.2 manual
	admits the limitation (gotta fseek(), rewind() or
	wait for EOF before changing directions.) I'll think
	about more intuitive behavior though.

		-Barry Shein


Received: by cca-unix.ARPA (4.12/4.7)
	id AA21074; Mon, 7 May 84 12:34:44 edt
Date: Mon, 7 May 84 12:34:44 edt
From: rmc@cca-unix (Mark Chilenskas)
Message-Id: <8405071634.AA21074@cca-unix.ARPA>
To: root%bostonu.csnet@csnet-relay.ARPA
Subject: Re:  How many printfs could a printf printf if a printf could printf printf
Cc: info-gnu@mit-mc.ARPA

	I like the idea too.  VMS uses a vectorized common run time 
library for system calls and "program language support routines" (ie
the equivalent of the various -l libraries + the standard C library)
which allows "the system" to modify and correct such routines on the
fly - you get the current copy without relinking.  The VAX was built
so that the extra indirection on call is not particularly expensive
but 68000s et al probably are not.  We might want to reconsider
using a vectored approach, but some sort of common storage for the
run time system seems a win in all the systems that use it.

						v
						Z

Date: 7 May 1984 12:31:15-EDT
From: gill at mit-ccc
To: info-gnu@mit-mc
Subject: Putting printf in the kernal.

Sounds like a bad idea. How much goes in the kernal is the result
of a tradeoff between minimality and efficiency. UNIX kernals
are not only minimal because of the PDP-11's address space. A small
set of powerful system calls makes it possible for a programmer to
easily know all the facilities at her disposal and prevents her from
getting locked into high level interfaces inappropriate for the
application. The applicability of UNIX to tasks undreamed of at its
conception proves the wisdom of the simple-but-powerful design
methodology. 

An IBM operating system manual is not light reading. Reading section
2 of the V7 UNIX manual takes no time at all and you immediately know
what's easy, what's hard, and what's impossible. If you then feel like
perusing the higher libraries to see if someone's already done some of your
work, rest assured that at no time will some obscure system hack rear its
ugly head.

I don't believe the disk space taken up by commonly linked library routines
nor the extra swap-in time penality of loading them into core are reason
enough to greatly increase the complexity of the kernal and destroy the
comprehensibility of the system environment. Today's memory and disk prices
make such penalities minimal. If you want dynamic linking (which is what you 
are talking about), then write another MULTICS. I've got news for you, though:
there won't be any complete single semester source-reading courses about it. 

	Gill Pratt

Date: Mon 7 May 84 11:05:08-EDT
From: Mark Plotnick <M.MP%MIT-EECS@MIT-MC.ARPA>
Subject: Re: Standards Fans...
To: root%bostonu.csnet@CSNET-RELAY.ARPA
cc: info-gnu@mit-mc.arpa
In-Reply-To: Message from "God <root%bostonu.csnet@csnet-relay.arpa>" of Mon 7 May 84 09:43:43-EDT

If you read the man page for fopen() you'll see why your
program doesn't work.  And yes, it's a limitation that doesn't
really need to be there and should be fixed.
	Mark
-------

Received: From bostonu.csnet by csnet-relay;  7 May 84 9:13 EDT
Received: by csvaxa.ARPA (4.12/4.7)
	id AA01915; Sun, 6 May 84 23:16:49 edt
Date: Sun, 6 May 84 23:16:49 edt
From: God <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8405070316.AA01915@csvaxa.ARPA>
To: info-gnu@mit-mc.arpa
Subject: Standards Fans...


I ran the following program on my 4.2BSD VAX system:

#include <stdio.h>
main()
{
	FILE *fp ;

	if((fp = fopen("tst","r+")) == NULL)
	{
		perror("fopen") ;
		exit(1) ;
	}
	putc('X',fp) ;
	putchar(getc(fp)) ;
	putc('Z',fp) ;
	putchar(getc(fp)) ;
}

on the following two line file (tst):

Hello World
This is a test

Nothing was printed on the terminal and the file ended up:

X^@Z^@o World
This is a test

Where ^@ is 00 octal. Should this be fixed/redefined in GNU
or is there something going on here I don't see?
(Richard, now you can see where I am getting confused.)

			-Barry Shein


Received: From bostonu.csnet by csnet-relay;  7 May 84 9:13 EDT
Received: by csvaxa.ARPA (4.12/4.7)
	id AA01731; Sun, 6 May 84 22:52:20 edt
Date: Sun, 6 May 84 22:52:20 edt
From: God <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8405070252.AA01731@csvaxa.ARPA>
To: info-gnu@mit-mc.arpa
Subject: How many printfs could a printf printf if a printf could printf printf


	It occurs to me that one silly thing in the UNIX
	environment is that there are several non-trivial
	routines (eg. stdio, printf family) which almost
	everything running on the system uses and holds a
	private copy of. This results in a waste of disk
	space (hundreds and hundreds of copies of printf
	binaries out there) and some loading overhead every
	time almost anything is run. There are two obvious
	solutions to this:

		1) Make the meaty parts of these routines
		system calls. Especially in the case of
		printf which the kernel has a version of
		anyhow. This was not originally done on
		the PDP11 because of address squeeze as
		far as I can tell, not for any holy reason.

		or

		2) Make it a shareable read-only text segment
		mapped into the text space of relevant processes.

It seems that as long as the current rules that any system
provided routine may be overridden by a user routine of the
same name remain. The only dangers I can see are that changes
in the common routine could break programs but no more nor less
than a change in the library routine (except that in the latter
case a program is protected till relinked.) I like the second idea
better as it could become a common system facility unique to GNU.
(Note: IBM uses a similar feature for IBCOM so this is not really
a new idea.) Ideas?

			-Barry Shein

Date: Sun 6 May 84 13:42:09-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: explanation
To: info-gnu@MIT-MC

In  struct bar { struct foo x;};  no variable of type foo is being declared,
only a structure field.  In principle there is no need for the size of foo
to be known until a variable is declared all or part of which is of type foo.
-------

Received: by sri-tsc.ARPA at 4 May 84 14:31:10 PDT (Fri)
Date: 4 May 84 14:31:10 PDT (Fri)
From: E. Howard Alt <alt%terra@sri-tsc>
Message-Id: <8405042131.AA01633@sri-tsc.ARPA>
To: rmc@cca-unix, rms@mit-mc
Subject: Re:  C Questions
Cc: info-gnu@mit-mc


I wish you would check out your code before you make stupid statements
like that.  If you wrote the code right, that wouldn't happen.  you
need a ; after the structure declaration.  how long have you been programming
in C?  Even with the syntax error, it seems to work fine on a 4.1 and a 4.2 system,
it did crash on my sun however.  if it is written right, it works everywhere.
C compilers have always had problems with ; left off of structure decls.



							Howard.

Received: by cca-unix.ARPA (4.12/4.7)
	id AA12154; Fri, 4 May 84 05:45:57 edt
Date: Fri, 4 May 84 05:45:57 edt
From: rmc@cca-unix (Mark Chilenskas)
Message-Id: <8405040945.AA12154@cca-unix.ARPA>
To: rms@mit-mc
Subject: C Questions
Cc: info-gnu@mit-mc

    To the best of my knowledge, the questions are answerable as
follows, mostly based on usenet traffic:

    Enums are enums and ints are ints.  Enums are not useful because
they do not assignable back and forth between ints.  Maybe you could
cast the enum to an int and make it work, but implicit assignment
conversion is not done here.

    Everyone agrees that supporting the obsolete constructs is
unnecessary, and that there will be much gnashing of teeth when they are
no longer supported "real soon now".  This issue has been circumvented
for over five years now...

    The void construct is primarily a documentation device and useful
for placating lint.  Many, many routines are functions used only for
side effect.  This includes such things as printf.  Lint complains if
you don't use the value returned by a function.  Void explicitly throws
the function's returned value away without having to say something like
junk = printf("Hi there!\n");

    To be honest i don't understand C scoping rules worth a damn.  I
know that structure elements redefine external function entry point
addresses in 4.2 bsd.  For example, this program fragment core dumps by
trying to branch off to absolute address 4:

struct blecche { int fstat; }
main()
{ printf("Hi there!\n"); }

The fstat in struct blecche is seen by the linker and fstat is called by
fopen which is called by fprintf...

    I don't understand forward references either.

    Hope this helps some at least.

                                                v
                                                Z

Received: from MIT-LISPM-5 by MIT-OZ via Chaosnet; 4 May 84 05:10-EDT
Date: Friday, 4 May 1984, 05:09-EDT
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Unclear aspects of C language
To: info-gnu at MIT-MC

I can design reasonable answers to the following questions,
but can anyone tell me what other C compilers do and
what users will be expecting?

*) Should assigning enumeral values to integer variables be allowed?
Should assigning integer values to enumeral variables be allowed?

*) When an enumeral value is used, is it converted automatically
to type int, just as char and short are?

*) If an enumeral value and an integer are added, what type is the result?
(Presumably this can happen only if the answer to the previous question is "no").

*) How important is it to support obsolete constructs such as
 x =+ 1;   or   x + = 1;   or   int x 5;

*) How important is it to allow references to components of
"the wrong" structure type?
  struct foo {int a,b;} x;
  ... x.c ...

*) What exactly does "void" mean?

*) Is it ok for me to make
  { int x;
    ...
    { int x = x;
      ...
    }
    ...
  }   

compile so that the inner declaration of x is initialized from the outer?
The vax unix compiler appears to make the inner x visible in its own initializer.
I suppose this allows one to write 
  struct cons {struct cons *car, *cdr;};
  struct cons x = {0, &x};  /* circular list! */
some variation of which might even be useful.
But do other compilers do things the same way?
Will it matter if I make that stop working?

*) How long can one defer defining a forward reference to
a structure or union tag?  Is it important to allow

  struct {struct foo *x;} y;
  struct foo {int a,b,c};

If so, what happens when someone refers to  *y.x  before
 defining foo?

What about

  struct bar {struct foo x;};
  struct foo {int a,b,c};

and then

  struct bar {struct foo x;};
  typedef struct bar BAR;
  struct foo {int a,b,c};

Is it ok for me to require that all cross-references in a type be resolved
before variables of that type are actually declared?

It appears to me that all structure references at one
level of name scoping must be resolved as soon as a deeper
level is about to be entered, to make sure that references
are not accidentally resolved pointing to definitions in
the deeper level and then visible after that level is exited.
Is this true?

  struft bar {struct foo *x,y;};

  int lose ()
  {  struct foo { int a,b,c; };
     ... }

  struct foo { double a,b,c;};

Is the structure bar supposed to be one thing inside lose
and a different thing outside lose?  Or is this an error?
Or is the x or y component of a bar treated differently
depending on where it is referred to?

Date: Fri 27 Apr 84 20:18:24-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: C preprocessor needed
To: info-gnu%MIT-OZ@MIT-MC.ARPA

I recall someone said he had a free version of the C
preprocessor, that handles the # lines.
Does anyone know who this is, or where I can find one?
I am going to need one soon.
-------

Received: from MIT-MC by MIT-OZ via Chaosnet; 11 Apr 84 17:38-EST
Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.24/4.25)
	id AA22711; Wed, 11 Apr 84 14:36:19 pst
Received: by ucbernie.ARPA (4.24/4.25)
	id AA12087; Wed, 11 Apr 84 14:37:15 pst
Date: Wed, 11 Apr 84 14:37:15 pst
From: phr%ucbernie@Berkeley (Paul Rubin)
Message-Id: <8404112237.AA12087@ucbernie.ARPA>
To: info-gnu%mit-oz@mit-mc.ARPA, rminnich@udel-ee.ARPA
Subject: Re:  Xinu

1. I asked Doug Comer whether he thought Xinu could be turned into a
	Unixoid system.  He didn't think much of the idea.  Xinu is
	intended mainly to support standalone programs on micros.

2. He plans to charge money for the tape (a few hundred dollars, last
	time I talked with him, although he may have changed his mind),
	so we probably can't redistribute his code.


Received: from MIT-MC by MIT-OZ via Chaosnet; 11 Apr 84 11:43-EST
Date:     Wed, 11 Apr 84 11:09:27 EST
From:     Ron Minnich <rminnich@udel-ee.arpa>
To:       info-gnu%mit-oz@mit-mc.arpa
Subject:  Xinu

   Got some replies on xinu. Yes, i know it is completely unrelated to unix;
and no, it is not that company in berkeley called Mt. Xinu or whatever. 
   The one I meant was the one in the book by Comer, which I just got a copy
of and am thumbing through. The publisher tells me there will be a tape
available; there looks to be a lot of stuff in there we could use; 
question is, if I get a tape i can probably ship it out if gnu people
think they can use it. It looks like a simple, straightforward little system
which one could build a Unix-equivalent interface to. In some ways I like
it better...
   Any thoughts?
   ron

Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Apr 84 09:45-EST
Date:     Fri, 6 Apr 84 9:38:37 EST
From:     Ron Minnich <rminnich@udel-ee.arpa>
To:       info-gnu%mit-oz@mit-mc.arpa
Subject:  do you still exist?

   Does this list still exist? 
   Anybody think we can use some of the Xinu stuff? Or are you all 
beyond that already.
  ron

Received: from MIT-ARTHUR by MIT-OZ via Chaosnet; 29 Mar 84 09:42-EST
Date: Thursday, 29 March 1984, 09:43-EST
From: DCB.TECH%MIT-OZ@MIT-MC.ARPA
Subject: unsigned chars, sizeof ptr
To: cbosgd!mark@UCB-VAX.ARPA
CC: info-gnu%MIT-OZ@MIT-MC.ARPA

I betcha 90% of the complaints about signed chars is when lint
complains about EOF being put into a char.  Stil and all, it seems to
be the only time where Bell Unix folks admitted they've made a mistake.

If you push everything on the stack as a full (say) 32 bits, then you've
effectively bypassed the problem of (char *)0 and 0 distinction.  Unisoft
does this...  Kind'a makes printf &co easy to write, too...

/rich$alz

Received: from MIT-ARTHUR by MIT-OZ via Chaosnet; 29 Mar 84 09:33-EST
Date: Thursday, 29 March 1984, 09:34-EST
From: DCB.TECH%MIT-OZ@MIT-MC.ARPA
Subject: NULL and all that
To: root%bostonu.csnet@CSNET-RELAY.ARPA
CC: info-gnu%MIT-OZ@MIT-MC.ARPA

Barry,
Your idea of changing NULL to nil is a good idea, but it sure ain't compatible
with the rest of the world.  As the C reference manual states:  "the value 0 may
be assigned to any pointer, and is presumed to mean a pointer not pointing at
anything." (Or words to that effect...)
	/rich$alz
ps:  what does yfnsm mean, anyhow?

Date: 27 Mar 1984 1004 PST
From: Eric P. Scott <EPS@JPL-VLSI>
Subject: NULL pointers
To: Info-GNU@MIT-MC.ARPA
Reply-To: EPS@JPL-VLSI

One of the nice things about VAX/VMS is that it normally leaves
page zero unmapped so you know very quickly that you have a null
pointer, even in cases like foo->bar; I've used machines where
address 0 traps, but, say, 14 does not--real hard to track down
bugs!  EUNICE starts executables at 0 with the claim that
"location 0 should be valid and contain 0" so there are enough
bytes of 0 there to make double pointers happy.  Writes trap,
reads do not.  It seems to me that someone got confused a long
time ago and it's been with us ever since.  I wonder how much
code depends on it!
					-=EPS=-
------

Date: 26 March 1984 22:13-EST
From: Ed Schwalenberg <ED @ MIT-MC>
Subject: NULL and all that
To: root%bostonu.csnet @ CSNET-RELAY
cc: INFO-GNU @ MIT-MC

	The problem obviously is the small chance that location 0
	really holds something of use.
No, the problem is people who think that a null pointer points at
something.  You check that p != NULL before checking anything at
all about *p.  Trying to reference *p when p == NULL may give you
the first instruction of your program, 0, a bus error, or any damn
thing the compiler chooses to have in the runtime environment at
location 0.  (In the PDP-11, you can have different things depending
on whether the compiler -i, -n, or -f options are used.)  The examples
on pages 103 and 107 of K&R are quite clear:
	if ((p = alloc(...)) != NULL) ...

Furthermore, the manual (K&R) is explicit on the original subject of
whether you need to say (char *)0:  "It is guaranteed that assignment
of the constant 0 to a pointer will produce a null pointer
distinguishable from a pointer to any object." (p. 192).  Note that
this sentence speaks of distinguishing pointers, not pointees.

Received: by UCB-VAX.ARPA (4.24/4.25)
	id AA20235; Sat, 24 Mar 84 17:39:09 pst
Date: Sat, 24 Mar 84 19:23:36 est
From: cbosgd!mark@Berkeley (Mark Horton)
Message-Id: <8403250023.AA09680@cbosgd.UUCP>
Received: by cbosgd.UUCP (4.12/3.7)
	id AA09680; Sat, 24 Mar 84 19:23:36 est
To: info-gnu@mit-mc.ARPA
Subject: unsigned chars, sizeof ptr

In particular, note that in many 68000 C compilers, sizeof (pointer)
is 4, sizeof (int) is 2.  Some 68K compilers use 4 byte ints, they
have fewer code porting problems but run 20-30% slower.

Some hardware has signed chars (e.g. vax, pdp-11), some has unsigned
chars (68K, 3B).  Portable code has to handle both.  It is not safe
to store negative numbers in a char.  Some C compilers go to great
lengths on unsigned hardware to make chars appear signed, this is silly.

	Mark

Received: by csnet-relay via xbostonu;  25 Mar 84 16:12 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA10333; Sun, 25 Mar 84 14:31:49 est
Date: Sun, 25 Mar 84 14:31:49 est
From: YFNSM <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8403251931.AA10333@csvaxa.ARPA>
To: info-gnu%mit-mc.arpa@csnet-relay.arpa
Subject: NULL and all that


	It seems wrong to me that the C convention is to use
	0 as NULL, usually meaning points at nothing for
	initial and error states. The problem obviously is
	the small chance that location 0 really holds something
	of use. We had some software here that assumed that on
	our IBM3081. What happened was that 0 was a legal address
	and usually contained a zero (it is the machine check PSW
	I believe). Everything went fine until we got intermittent
	hardware problems which (correctly) caused non-zero values
	to be stored in location zero. Consequently, the editor
	would crash randomly and mysteriously. End of war story.
	Now a suggestion: Without changing anything in C one could
	certainly do something like:

	char *nil = nil ;
	#define NULL nil ;

	guaranteeing that nil be a unique address that points to
	itself (a la LISP.) The cost is one word. The problem is
	that now NULL is typed. The obvious extension is a la Pascal
	(lord forgive me) or PL/1 where nil becomes a keyword and
	inherits whatever type is necessary. This only requires that
	the code generator be able to place 'nil' on a sufficiently
	general boundry, I believe that is not unreasonable. Given
	that two changes are needed, one easy the other a nuisance.
	Change one is to find all the .h files (maybe only stdio.h)
	and change '#define NULL 0' to '#define NULL nil'. The hard
	part is to find all the code that assumes in other ways that
	NULL == 0, especially in conditionals like while(fgets()).
	This could be made easier if a switch in the compiler disallowed
	using 0 as an untyped constant thereby producing enough warning
	messages on a recompile to render this an editing job.

				-Barry Shein


Received: from MIT-MC by MIT-OZ via Chaosnet; 24 Mar 84 17:38-EST
Date: 24 Mar 1984 1435 PST
From: Eric P. Scott <EPS@JPL-VLSI>
Subject: Re: proposed C change and new features
To: Info-GNU%MIT-OZ@MIT-MC.ARPA
Reply-To: EPS@JPL-VLSI

Pointers vs. Integers:  0 is \not/ good enough; (char *)0 is.
Can you make the assumption that sizeof (foo *) == sizeof (int) ?
I don't think so!  In any case, pointers of different types are
not interchangeable, so I wouldn't necessarily expect pointers
and integers to be.  I expect
	foo *x;
	if (!x) ...
to be equivalent to
	if (x==(foo *)NULL)
however.  (I'm getting off the subject...)
-------
Unsigned Characters:  All that is required is that "the normal
character set" be effectively unsigned; I'm perfectly happy with
7-bit ASCII in 8-bit bytes.  Those of us who use C on strange
architectures to talk to weird (nothing at all like Un*x)
operating systems very much appreciate having "char"s being
signed, "unsigned char"s not, and struct members not
automagically naturally aligned.  The biggest deficiency here is
not being able to easily describe structures whose first element
does not have a zero offset.
					-=EPS=-
------

Received: by csnet-relay via xbostonu;  24 Mar 84 16:12 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA05627; Sat, 24 Mar 84 14:36:15 est
Date: Sat, 24 Mar 84 14:36:15 est
From: YFNSM <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8403241936.AA05627@csvaxa.ARPA>
To: info-gnu%mit-mc.arpa@csnet-relay.arpa
Subject: Dennis Ritchie Lecture


	I urge and implore all GNU people to come to Dennis
	Ritchie's lecture here at Boston U. If it is possible
	you don't already know he was one of the original
	designers of UNIX and should give GNU people some
	insight into the original goals. I know it was on the
	bboard, this is just a reminder:

		Dennis Ritchie
		The Evolution of the UNIX Time Sharing System
		Monday March 26, 4PM (Tea @3:30)
		BU Computer Science 111 Cummington St, Room 132

	Directions: Cummington Street is the road that goes off
	and back to Comm Ave behind the 700 Comm Ave towers.
	The Nickelodeon Movie Theatre is on Cummington Street.
	111 is at the far western end, directly behind the Store 24.
	The entrance door is not 111, follow back east towards the
	Nickolodeon and go in the first public door and look for the
	room number (construction recently bricked in 111, I think the
	number now is 64 Cummington or thereabouts.)

			-Barry Shein


Date: Sat, 24 Mar 1984  13:34 EST
Message-ID: <DCB.TECH.12001941699.BABYL@MIT-OZ>
From: Rich $alz <DCB.TECH%MIT-OZ@MIT-MC.ARPA>
To:   info-gnu%MIT-OZ@MIT-MC.ARPA
Subject: proposed C change and new features
In-reply-to: Msg of 5 Mar 1984  22:16-EST from God <root%bostonu.csnet at csnet-relay.arpa>

1.  type-checking.  there current work of the ansii committee is suggesting
     exactly like what mark weisner mentioned, also allowing an excape hatch
     for printf &c:
	extern void fprintf(FILE *, char *,);
     where the trailing comma means additional unspecified args, as in lint's
      varargsX construction.
2.  from what I' ve found, and the unix-wizards folks seem to agree, the only
    problem is with pointers things vs integers:  is just saying 0 good enough,
    or do you need to say (char *)0?  I favor and use the latter -- at least because
	it's much more clear...

3.	printf can  be written in c the same way on all but the most pathological
	machines, can't it:  if printf starts off like so:
		printf(x) int x; and from then on uses *x++ to get its args...

4.	the biggest changes are void, meaning this function rturns no value,
	and doing (void)write(1, buf, 56); to mean i'm only interested in the
	side -effects.  next comes enumerated types -- enum -- and structure
	assignment and all-by-valuing.  (RMS:  i will drop off a page detaliing
	this stuff -- it's in later editions of vol2 (i.e. v7+))
5.	I hope gnu's characters are UNSIGNED!  As SC Johnson says in his paper on
	lint, "thius may be considered to be a bug in the pdp11 hardware that
	made its way into the language.... if we had the time to fix it now,
	we would"

	/rich$alz

Received: from MIT-CCC by MIT-OZ via Chaosnet; 15 Mar 84 23:34-EST
Date: 15 Mar 1984 22:45:13-EST
From: opus at mit-ccc
To: info-gnu@mit-oz
Subject: a new Learn


	I am very interested in writing some documentation for gnu. 
I've already spoken to RMS about it. He says he'll take it as long as 
it's good.  I've done some for CCC already in their new "help" command.
I feel that this is a useful feature for a UNIX-type system to have. From 
short one-line entries that just explain some of UNIX's more obscure 
commands such as rm, to ideas like directories which can be confusing 
to first-time users, it makes a bridge between the very elementary learn
program and the highly technical standard manuals. 
	I need a C hacker, pref. in the Boston area. With someone working 
with me for the programming, I would be very interested in writing a bit 
more difficult learn program, one aimed at a crowd a few years older than 
the original audience. I figure we could push it all the way to high-school 
level. I am also interested in writing documentation for gnu in the form of 
a help command. 
	As Phil Servita puts it "Learn is written for people who think
mathematically, but are also raving twits." As Larry DeLuca said, "Learn
is written to teach another computer." So, to rescue those who can neither
conceptualize mathematically (where n+1 is ...) nor are raveing twits and
maybe have never seen a computer before, I would like to write a new
learn. It can be done with considerably less verbiage than it has now.
It can also be made tolerable for first-time UNIX users with a wider range
of previous computer experiance. 
	Obviously, there's no rush on this. I am going to be spending
the next few months analyzing the old Bell Labs Learn program to get
ideas about what to do, what NOT to do, and how to approach the
situation. It would be nice if the Learn wound up being generically UNIX
compatible, with maybe only minor modifications needed if a given system
is very different in some way. It should be possible since it would only
deal with the user level of things, of which the basics don't change
much from version to version. 
	
					Sincerly,	

						Stacey Goldstein
						(opus@ccc)

Received: from MIT-CCC by MIT-OZ via Chaosnet; 15 Mar 84 22:45-EST
Date: 15 Mar 1984 22:45:13-EST
From: opus at mit-ccc
To: info-gnu@mit-oz
Subject: a new Learn


	I am very interested in writing some documentation for gnu. 
I've already spoken to RMS about it. He says he'll take it as long as 
it's good.  I've done some for CCC already in their new "help" command.
I feel that this is a useful feature for a UNIX-type system to have. From 
short one-line entries that just explain some of UNIX's more obscure 
commands such as rm, to ideas like directories which can be confusing 
to first-time users, it makes a bridge between the very elementary learn
program and the highly technical standard manuals. 
	I need a C hacker, pref. in the Boston area. With someone working 
with me for the programming, I would be very interested in writing a bit 
more difficult learn program, one aimed at a crowd a few years older than 
the original audience. I figure we could push it all the way to high-school 
level. I am also interested in writing documentation for gnu in the form of 
a help command. 
	As Phil Servita puts it "Learn is written for people who think
mathematically, but are also raving twits." As Larry DeLuca said, "Learn
is written to teach another computer." So, to rescue those who can neither
conceptualize mathematically (where n+1 is ...) nor are raveing twits and
maybe have never seen a computer before, I would like to write a new
learn. It can be done with considerably less verbiage than it has now.
It can also be made tolerable for first-time UNIX users with a wider range
of previous computer experiance. 
	Obviously, there's no rush on this. I am going to be spending
the next few months analyzing the old Bell Labs Learn program to get
ideas about what to do, what NOT to do, and how to approach the
situation. It would be nice if the Learn wound up being generically UNIX
compatible, with maybe only minor modifications needed if a given system
is very different in some way. It should be possible since it would only
deal with the user level of things, of which the basics don't change
much from version to version. 
	
					Sincerly,	

						Stacey Goldstein
						(opus@ccc)

Date: 14 Mar 1984 12:19:19-EST
From: rmc@CCA-UNIX (Mark Chilenskas)
To: info-gnu@mit-mc
Subject: DECnet, SNA et al

	Many communications protocols are not proprietary.  DECnet protocols are
explicitly in the public domain, as DEC was hoping lots of companies would try
to adoppt it as "the only viable alternative to SNA".  IBM does not try to make
SNA proprietary, there are lots of SANA emulators on the market.  They could
probably do so if they chose to, as they make no claims about it being in the
public domain.  In fact tehhe major worry about SNA is that it can change
pretty quickly if IBM thingks a new product is important enough to cut down.
This happened to Ahmdahl and the other plug compatibles in the early to mid
70s - all o ff a sudden, lots of things that secondary vendors were counting
on in the operating system sor t of got losted...

					v
					Z

Received: by csnet-relay via xbostonu;  13 Mar 84 19:55 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA13455; Tue, 13 Mar 84 16:47:18 est
Date: Tue, 13 Mar 84 16:47:18 est
From: God <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8403132147.AA13455@csvaxa.ARPA>
To: info-gnu%mit-mc.arpa@csnet-relay.arpa
Subject: Reply to Andy Cromarty

	
	In fact I am trying to be involved. That is not the point. Unless
	GNU completely replaces the entire software environment there will
	still be machines that it will need to (for example) speak to.
	Writing reasonable network drivers without sources (eg) is nigh on
	impossible (ie. whatever is used on the GNU end will probably need
	to be put on the other end. That would leave us only a few
	unacceptable choices: 1) Try to do it anyhow 2) wait for the
	vendors to write something compatible with whatever networking
	software GNU decides to use (note that nothing currently being
	used satisfies that criteria, TCP comes close but not quite mostly
	due to hardware interfaces people choose to support) 3) Try to
	write drivers for whatever ridiculous network solutions the
	vendors come out with (decnet,sna) which very well might raise the
	ugly proprietary head again. Ideally, I would wish that GNU would
	be an attempt (among others) to provide both ends of a networking
	solution, this is another matter: Richard, any thoughts?
	
				-Barry Shein
	

Date: 13 Mar 84 12:06:04 PST (Tue)
From: Andy Cromarty <andy@aids-unix>
Subject: Source code moralizing
To: info-gnu@mit-mc


  Perhaps a good substitute for flaming is to do what the people on
this list are ostensibly gathered to do: write a good software system
and make its sources available for free.  Once free sources can be had
for whatever programs one wants, the presence of people who would like
you to pay for binary-only software releases becomes rather irrelevant,
don't you think?

Received: by csnet-relay via xbostonu;  13 Mar 84 12:13 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA11273; Tue, 13 Mar 84 11:54:32 est
Date: Tue, 13 Mar 84 11:54:32 est
From: God <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8403131654.AA11273@csvaxa.ARPA>
To: info-gnu%mit-mc.arpa@csnet-relay.arpa
Subject: Reply to Hartwell


	1. Re: ...like supplying blue prints to your car's
	engine...

		Funny, most vendors provide you with
		complete hardware schematics free.

	2. Re: ...not having the compiler...

	(which is almost always BLISS or PLS) Using
	compilers you are not likely to have is of
	course a double whammy as now they can sell
	you the compiler. (Of course, IBM won't sell
	you PLS as far as I know.) If it is a reasonable
	compiler that people generally buy then it is
	akin to getting the right tool to fix your car,
	you should acquire the compiler.

	I apologize if my paraphrasing changed the sense of anything
	you were saying, just keeping the bytes down and assume
	everyone read the original.

			-Barry Shein

Received: From Su-Shasta.arpa by csnet-relay via smtp;  13 Mar 84 4:54 EST
Date: Tuesday, 13 Mar 1984 01:33-PST
To: God <root%bostonu.csnet@csnet-relay.arpa>
Cc: info-gnu%mit-mc.arpa@csnet-relay.arpa, 
    nfo-gnu%mit-mc.arpa@csnet-relay.arpa
MMDF-Warning:  Parse error in preceeding line at csnet-relay.arpa
Subject: Re: A suggested patch to the law
In-Reply-To: Your message of Mon, 12 Mar 84 23:53:20 est.
             <8403130453.AA06970@csvaxa.ARPA>
From: Steve Hartwell <hartwell%su-shasta.arpa@csnet-relay.arpa>

Good grief.

I fail to see how software sold without sources cannot meet the requirement
that the product must perform "as can be reasonably expected" [sic].
Most software sold works, more or less, as promised; certainly as well
as any other product such as automobiles.

What you want is /not/ what they are selling.  You have the same rights
with your automobile as you have with binary software: you may use it
and modify it as you like, and risk warranty (support) if you modify it.
Asking for the sources is like asking for the blueprints of your
engine -- it is at the vendor's discretion to provide that information
(at any price of his choosing) or withhold it if he wants.  Without
the blueprints, the car still runs, and the compiler still compiles.
If it breaks, depending on your warranty, you may or perhaps may not
have the right to petition the vendor, depending on your purchase
agreement.  And /that/ is the definition of Warrant of Merchantability.

If you believe that the reason vendors withhold sources is that "it
would make the product difficult to support" then they have indeed
made a fool of you.

I believe that there are a variety of good reasons why vendors ought to
distribute their sources; Richard's view that withholding software
robs us of the opportunity to learn and exchange ideas is certainly
arguable, as is the position that the benefits of doing so will make
the vendor's product more attractive.  But to argue that source distribution
ought to be required is patently [pun] absurd.

Besides, what would you say to vendors whose software is written in a
language for which you have no compiler?

Steven Hartwell, Stanford University

Date: Tue 13 Mar 84 03:13:24-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Re: A suggested patch to the law
To: root%bostonu.csnet@CSNET-RELAY.ARPA
cc: info-gnu@MIT-MC
In-Reply-To: Message from "God <root%bostonu.csnet@csnet-relay.arpa>" of Tue 13 Mar 84 03:06:08-EST

Why don't you simply institute a miracle and change the situation?

If you don't, I will have to go ahead with your impeachment procedings.
First mousetrapping us into "original sin" and now this??
-------

Received: by csnet-relay via xbostonu;  13 Mar 84 2:30 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA06970; Mon, 12 Mar 84 23:53:20 est
Date: Mon, 12 Mar 84 23:53:20 est
From: God <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8403130453.AA06970@csvaxa.ARPA>
To: info-gnu%mit-mc.arpa@csnet-relay.arpa
Subject: A suggested patch to the law


I would like to use this forum to address a topic that distresses
me but I know no solution to.

There is a legal protection for consumers known as a "Warrant of
Merchantability". I assume you know what this is but simply stated
it guarantees that something sold you performs as it is claimed or
(importantly) performs as can be reasonably expected even in the
absence of claim.

I contend here that software sold without sources cannot meet that
test.

The claim by software vendors is that if they provide sources you
may make changes that would make it difficult for them to support
the software. Based on that reasoning the hood of my car should be
locked from me until its warranty runs out. In fact, if I make a
change in my car's engine I may very well void any warranty but
that was my choice.

The only reason software is sold without sources is that it can be
sold relatively cheaply (get the sucker hooked) and then later the
sources (which become necessary) can be sold at outrageous prices,
often 10X the cost of the binaries.

If software manufacturers were forced to sell software with
sources they would necessarily be reasonably priced or else no one
would buy that software.

The problem generally comes up in three ways. 1) There is a
serious bug in the software 2) There is a missing feature that
renders it useless or 3) One needs to support something the vendor
has a vested interest in you not supporting (eg. a terminal not
sold by the vendor.)

In my opinion only a fool buys a critical piece of software
without the sources. I have been such a fool once or twice and I
always seriously regretted it. Obviously a game or some such is
irrelevant but your OPERATING SYSTEM????

What is the answer? A court battle? A boycott? both? suggestions
begged! This is an issue we have too long been sheepish on
allowing software vendors to make fools of us convincing us we do
not need the sources and then trying to sell them to us later when
it becomes obvious that they lied.

Date: 8 Mar 1984 1647 PST
From: Eric P. Scott <EPS@JPL-VLSI>
Subject: Re: suffer a C change?
To: Info-GNU@MIT-MC.ARPA
Reply-To: EPS@JPL-VLSI

I seem to recall two or three CSTRs a few years back describing
optional argument type checking for C and a preprocessor that
added S[l]imula-style classes.  Mark?
					-=EPS=-
------

Received: by UCB-VAX.ARPA (4.22/4.25)
	id AA05114; Thu, 8 Mar 84 16:13:34 pst
Date: Thu, 8 Mar 84 18:07:27 est
From: cbosgd!mark@Berkeley (Mark Horton)
Message-Id: <8403082307.AA03255@cbosgd.UUCP>
Received: by cbosgd.UUCP (4.12/3.7)
	id AA03255; Thu, 8 Mar 84 18:07:27 est
To: info-gnu@mit-mc.ARPA
Subject: Re:  suffer a C change?

The C language does not currently know about the types of arguments
expected by a function.  In general, the calling routine will widen
float to double, char and short to int, and turn char[] into char *,
when passing arguments to functions.  As I understand it, the C
standards committee at Bell Labs in MH (I forget the name of the
person in charge, was it Larry Rossler?  Perhaps someone remembers)
has an extension on
the drawing board to OPTIONALLY convey type information, so that
things would be upward compatible, but you could declare the
expected types in a function declaration (e.g. the equivalent of
a Pascal "forward" decl.)  Also note that lint, if the programmer
uses it, will check for type compatibility among arguments and
parameters.

The extensions to the C language since the C book are as follows:

V7:
	enumerated types (virtually unusable due to an overly strict
	implementation in pcc).

	structure assignment

	structures may be passed as parameters to functions by value,
	and functions may return structures.  (Still no provisions for
	arrays by value, due to an ambiguity whose details I forgot,
	but you can always put an array inside a structure.)

S III:	new built in "void" type, e.g.
	(void) write(1, "hi\n", 3);
	to stop lint from griping about the ignored return value.

4BSD and Sys V rel 2:
	flexnames: names are no longer chopped at 8 characters, but
	are fully significant.  (I think the implementations actually
	chop at 256, but the symbol table is oranized using a string
	table and is actually smaller for most programs.)


The planned extensions include the parameter type checking mechanism
above and a readonly parameter type.  I think there are others planned.
In any case, if you're contemplating an extension to check types of
functions, you should be compatible with the planned extension.

By the way, printf can indeed be written in C, and a C implementation
exists.  It uses <varargs.h>.  The secret is in knowing that the format
itself tells the type of the next expected argument.  This implementation
was present in UNIX/TS 2.0 and I think may have been in System III, but
was eventually replaced by one written in assembler because the C
Version was too big and too slow for such a heavily used routine.

	Mark

Date: 7 Mar 1984 16:27:04-EST
From: gill at mit-ccc
To: info-gnu@mit-mc
Subject: Mark Weiser's comment about printf.
Cc: syspeople@mit-ccc

The trouble is not that printf doesn't know how many arguments there are,
but that it can't express at compile time what their type will be.
Writing printf in C is no different from writing it in assembly; you still have
to know how various types of arguments will align themselves in the
calling stack frame. Writing printf in C is more of a kludge than doing
it assembly because it doubly hides what is "really" going on.
Writing printf in a C with automatic argument coersion
will be an even bigger kludge.

Automatic argument coersion for C is a bad idea. The only reasonable
implementation will be to hair up the linker to insert the appropriate code
during calls. It can't be done in the compiler without putting in awfull
stuff like lines saying what files a program is going to be linked with. I
find this revolting. Doing it in real time will make the C calling sequence 
even more expensive then it is already; this is intolerable.

My sugestion is to implement argument type checking, not coersion. It is
easy to include in the object file symbol table information about argument
number and type. The linker can check this information and give you warning
messages about it. A utility program can print out for the programmer the
correct argument structure for any function in any library or object file.
In this way, a programmer won't get screwed by giving a function a bad
argument, even though he isn't up to placating lint.

I am writing you all not so much to argue this C language issue, but
to urge you to not waste your time on it. If there is one thing that
will make GNU worthless, it is "improvements" such as these to what a
user now sees under UNIX. Evolution is the only proper method of improving an
old computer system. Haggling over paper designs wastes everyone's time and
usually results in stupid ideas. Just look at the dozens of "UNIX like"
systems out there that make you want to pull your hair out everytime you come
across another one of their "better ideas." If you forget the initial
goals of GNU (making a public domain, UNIX compatible operating system)
you will not only waste your time not getting it done, but will also build
something very few people will want to use.

And just so 80% of you will hate my guts ...

Tinkering with C while trying to replicate UNIX is
sort of like spending your time convincing evangelists that kids
should pray in school while the world stands at the brink of self 
destruction. 

To borrow a prayer a collegue composed today:

	Dear Lord, I pray that as I sit here at the broken desk my
school couldn't afford to replace, and listen to the stupid teacher
my schold couldn't afford to fire, that I won't be incinerated,
my shadow etched in the floor because some stupid idiot in Washington
couldn't think of anything better to do.

	Have a nice day,

		Gill Pratt

Date: 7 Mar 1984 15:29:42-EST
From: rmc@CCA-UNIX (Mark Chilenskas)
To: info-gnu@mit-mc
Subject: C and type checking arguments

	This issue was debated a while back on the USENET net.lang.c group.
The consensus seemed to be that, yes, type checking arguments might be
useful in some cases but that any compiler which did so Would Not Be C.
After all, the Bible says that the world was created in seven days, and
the White Bible says that there is no type checking on procedure
arguments.  One does not argue with God.

						R Mark Chilenskas
						Chilenskas@CCA-VMS
						rmc@CCA-UNIX

Received: from MIT-MC by MIT-OZ via Chaosnet; 7 Mar 84 14:48-EST
Date:  7 Mar 1984 at 1135-PST
To: root%bostonu.csnet at CSNET-RELAY.ARPA
cc: info-gnu%oz%mit-mc.arpa at Sri-Tsca
Subject: Re: enumerated types.
In-reply-to: Your message of 6 Mar 1984 20:58:30-PST
From: alt at Sri-Tsca


yes, people do use enumerated types.  It is not clear to me WHY they
do, but they do.  It is used in the berkeley unix kernel B_READ and
B_WRITE argument to physio().  I think I might have seen in some place
else too.  They probably just decided that since it was there, they 
might as well use it.

				Down with enums,
					Howard.

Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 7 Mar 84 13:20-EST
Date: Wednesday, 7 March 1984, 13:21-EST
From: Richard Mlynarik <Mly%MIT-OZ@MIT-MC.ARPA>
Subject: I think they're getting worried
To: info-gnu%MIT-OZ@MIT-MC.ARPA
Message-ID: <[MIT-LISPM-18].7-Mar-84 13:21:23.Mly>

Date: Mon, 5 Mar 84 07:47 EST
From: Kahin@MIT-MULTICS.ARPA

Massachusetts Research
Institute Program on
of Technology Communications Policy

		       THE EFFECT OF REPRODUCTION
			     TECHNOLOGIES ON
			  INTELLECTUAL PROPERTY
				    
THURSDAY, MAR. 22, 1984 4-6 PM
MARLAR LOUNGE, BUILDING 37-252
70 VASSAR ST. CAMBRIDGE


STANLEY BESEN, THE RAND CORPORATION
CAROL RISHER, ASSOCIATION OF AMERICAN PUBLISHERS
MARIO BAEZA, DEBEVOISE & PLIMPTON/HARVARD LAW SCHOOL

     New reproduction technologies -- photocopiers, videocassette
recorders, computers -- threaten copyright owners with loss of
control over their product.  But it is difficult to calculate
actual or potential losses, or to determine whether these losses
actually impair the incentive to create intellectual property.
Regulatory solutions, such as redistribution of compulsory
license fees on copying equipment and materials, have been
proposed but involve additional costs and raise difficult
administrative and policy problems.  Dr.  Besen is finishing an
NSF-funded project that develops economic models for the problem
of "home" copying and analyzes the production, distribution, and
pricing policies of firms that face the problem..
------------------------------

Date: 6 March 1984 21:18-EST
From: Andrew Scott Beals <BANDY @ MIT-MC>
Subject:  Re: suffer a C change?
To: RMS @ MIT-OZ
cc: INFO-GNU @ MIT-MC, CAL @ MIT-OZ
In-reply-to: Msg of Mon 5 Mar 84 23:33:28-EST from RMS%MIT-OZ@MIT-MC.ARPA

Printf could and Is written in C.

Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Mar 84 20:32-EST
Received: by csnet-relay via xcase;  6 Mar 84 3:20 EST
Date: 6 Mar 1984 01:45:52-PST
From: diamant%case.csnet@csnet-relay.arpa
To: info-gnu%mit-oz@csnet-relay.arpa, mit-mc%case.csnet@csnet-relay.arpa
MMDF-Warning:  Parse error in preceeding line at csnet-relay.arpa
Subject: Re: suffer a C change?

Richard,
You are correct in saying that C compilers know nothing about the types
of the parameters that functions expect.  The only conversions that take
place are normal expression conversions.  I quote from K&R:

	"Since a function argument is an expression, type conversions
	also take place when arguments are passed to functions:  in
	particular, char and short become int, and float becomes
	double."

I seriously doubt that too much code would intentionally use this, as
type casts are always available when a particular type conversion is
needed.  On the other hand, functions like printf and scanf couldn't
possibly know what types of parameters they want -- it depends on the
first argument (even the number of parameters).  There is always a
danger in doing things like automatic type conversions, though, if they
are not standard.  I would say, at the least, you should make a compile
switch which defeats the feature, in case it does cause a program to
break.  It would be nice if it would allow you to do type checking and
generate a warning message when the types do not match.


					John Diamant
					diamant@Case.csnet
				or	diamant.Case@Rand-Relay.arpa

Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Mar 84 20:31-EST
Received: by csnet-relay via xbostonu;  6 Mar 84 3:14 EST
Received: by csvaxa.ARPA (4.12/4.7)
	id AA00036; Mon, 5 Mar 84 22:16:28 est
Date: Mon, 5 Mar 84 22:16:28 est
From: God <root%bostonu.csnet@csnet-relay.arpa>
Message-Id: <8403060316.AA00036@csvaxa.ARPA>
To: info-gnu%oz%mit-mc.arpa@csnet-relay.arpa
Subject: proposed C change and new features


	Typing parameters would have its largest effect in
	the C I/O library. An illustrative example is:

		int i ;
		float x ;

		printf("%d",i) ;
		printf("%f",x) ;

	you would need primitives to correctly pluck that apart
	inside the routine. This might not be bad but ripples
	all over the standard libraries. I would think real hard
	before implementing the proposed change. Personally I liked
	(in spirit) the way PL/I did it where you could (in C-ese):

		int foo((float),(int *)) ;

	in which case the two args would be checked and coerced or if
	dcl'd as:

		int foo() ;

	no checking or coercing occurred, you got as much as you asked
	for.
	You would have to give serious thought to routines (such as
	printf) which take variable number of arguments, how could
	it even be declared??
	The way a printf is typically handled now is to take the
	address of the first parameter and assume that arguments
	come in multiples of words and are contiguous in memory.
	(note that the answer to your question is yes in one case,
	char args are coerced to ints).

	Later features: The two most salient I know of are enumerated
	types (apples, oranges, pears) a la' Pascal which I may be
	wrong but do not think anyone ever uses in C (#define is more
	in the spirit of C and can accomplish the same thing more or
	less.) The other is aggregate type support such that you
	can assign and pass as args structures which I believe is
	widely used.

Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Mar 84 20:09-EST
Received: by csnet-relay via umcppo;  5 Mar 84 22:34 EST
Date:     5 Mar 84 22:16:31 EST  (Mon)
From:     Mark Weiser <mark%umcp-cs.csnet@csnet-relay.arpa>
Subject:  Re:  suffer a C change?
To:       RMS%MIT-OZ%mit-mc.arpa%csnet-relay.csnet@csnet-relay.arpa, 
          info-gnu%MIT-OZ%mit-mc.arpa%csnet-relay.csnet@csnet-relay.arpa

Type checking arguments could not screw up too much, for the simple
reason that portable C code forces arguments to match in type anyway.
This is because different datatypes may be of different lengths
on the stack, even pointer vs. integer.   So the careful programmer
has learned not to be to tricky with arguments, but to coerce the
type explicitly to the proper thing before the call.

About the only case I can recall of passing the wrong types
involves passing longer integers instead of shorter integers, 
which I occasionally do.  But this is not a trick, just laziness.

Received: by csnet-relay via umcppo;  6 Mar 84 0:51 EST
Date:     6 Mar 84 00:41:31 EST  (Tue)
From:     Mark Weiser <mark%umcp-cs.csnet@csnet-relay.arpa>
Subject:  Re: suffer a C change?
To:       RMS%MIT-OZ%mit-mc.arpa%csnet-relay.csnet@csnet-relay.arpa, 
          CAL%MIT-OZ%mit-mc.arpa%csnet-relay.csnet@csnet-relay.arpa
Cc:       info-gnu%mit-mc.arpa%csnet-relay.csnet@csnet-relay.arpa

Actually, printf can be written in C, albeit slightly differently
for each machine it is written on.  I have done so for Vaxes.
After all, the number of arguments is hidden away right there in 
the first field.

I agree with the conclusion that introducing argument type checking
does not screw anything up.

Received: from MIT-MC by MIT-OZ via Chaosnet; 6 Mar 84 05:52-EST
Return-Path: <efrem@lbl-csam>
Received: by lbl-csam.ARPA ; Tue, 6 Mar 84 02:54:31 pst
Date: Tue, 6 Mar 84 02:54:31 pst
From: (Efrem Lipkin [DBG]) efrem@lbl-csam
Message-Id: <8403061054.AA05621@lbl-csam.ARPA>
To: info-gnu%mit-oz@mit-mc
Subject: parameters in C and datatype extension

Given that C does not have a facility for definining and using classes
or doing other kinds of datatype extension and detail hiding,  C's lack
of parameter conversion is very handy and frequently exploited.  A
programmer develops new data types by creating a series of subroutines that
take blocks of memory or pointers to memory (that hold the representation
for the type) as parameters and implement the operations of the type.

The user of the type does not know the internal structure of the data and
frequently has it defined differently, than its defined in the manipulating
routines.  For instance, most C compilers can not pass structures, but many
routines pass small structures around by hiding them in longs.

People exploit many of the quirks of the ancient C compilers forcing the
newer ones to reflect some of their marginal properties.  For example,
C let's one take the address of a parameter and most implementations pass
all parameters on the stack.  Some programs take advantage of this to
treat the stack frame as a structure or array or to rapidly step through
parameters.


Date: Mon 5 Mar 84 23:33:28-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Re: suffer a C change?
To: CAL%MIT-OZ@MIT-MC.ARPA
cc: info-gnu@MIT-MC
In-Reply-To: Message from "Cliff Lasser <CAL%MIT-OZ@MIT-MC.ARPA>" of Mon 5 Mar 84 23:30:48-EST

The Pastel language has facilities for functions taking variable
numbers of arguments of any type -- the function can find out at run time
what type was supplied.  PRINTF could not be written in C, unless I extend C,
but it could be written in Pastel (in fact, there already is one) and called
from C programs.  So PRINTF is not screwed by introducing argument type checking.
-------

Date: Mon 5 Mar 84 18:50:46-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: suffer a C change?
To: info-gnu%MIT-OZ@MIT-MC.ARPA

Am I correct in believing that C compilers know nothing
about what types a function expects its arguments to have?
That no attempt is made to convert the expressions that the user writes
to the data types that the function will assume?

If this is true, do you think that much C code takes advantage
of this to pull weird tricks?  Would it be a disaster for a C
compiler to know what type each argument should be
and convert the actual parameter to that type before passing it?
The compiler I am modifying already has the ability to do this
and will do it if I don't make it stop.  This would also be
a great improvement--provided it doesn't screw everyone.
I hope you can tell me whether it would screw everyone.

Also, does anyone have information to send me on extensions
to C made since the book was written?  I need this in order
to make the parser I am writing handle them.  I have been 
told that this is in part of the Unix manual, but when I looked
there the information given was incomplete and omitted some
extensions I have been told were made.  If you have the full
specs, please send them to me.
-------

Date: Thu 1 Mar 84 02:16:03-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: YACC doc
To: info-gnu@MIT-MC

Can someone please give me the documentation on using YACC?
I cannot find this anywhere.
-------

Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 22 Feb 84 14:17-EST
Date: Wednesday, 22 February 1984, 14:18-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: object file format
To: info-gnu at MIT-MC, eak at S1-A.ARPA, sklower at UCBDALI.ARPA

Can anyone tell me whether the order of bytes
in the relocation data, symbol table, etc. of an a.out file
is different between vaxes and 68000's?

Date: Tue 21 Feb 84 17:23:06-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Current progress
To: info-gnu@MIT-MC

I have nearly got the Livermore pascal compiler producing
68000 object code.  The next step is to get the compiler
to actually run on a 68000, and to write the C front end.

Progress is continuing on the TRIX kernel, and the assembler
shows some signs of life.

I would really like someone to write a linking loader.
-------

Date: Mon 20 Feb 84 21:04:49-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Damn you, rumor inventor.
To: info-gnu%MIT-OZ@MIT-MC.ARPA

Someone decided to tell people I was moving to Berkeley.
Someone else decided to tell people that I was going to
work for Megatest.

I'm not, and I never was.  Someone who knows a tiny bit
about my activities or plans must not know or not care about
the difference between facts and imagination.

Whoever you are, I am angry you have misinformed so many people
and given me the trouble of straightening them out.
-------

Received: from MIT-MC by MIT-OZ via Chaosnet; 15 Feb 84 21:27-EST
Date: 15 February 1984 21:19 EST
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject:  ensuring (insuring?) the gnu philosophy.
To: RMS @ MIT-OZ
cc: info-gnu @ MIT-OZ
In-reply-to: Msg of Wed 15 Feb 84 00:28:22-EST from RMS%MIT-OZ at MIT-MC.ARPA

    Date: Wed 15 Feb 84 00:28:22-EST
    From: RMS%MIT-OZ at MIT-MC.ARPA

    I don't mind if some large companies eventually use GNU.
    I do wish to prevent them from eventually achieving de facto
    ownership of GNU.  For this reason, I do not plan to put the
    code I write in the public domain.  I want to permit use of it
    on precisely defined terms, which require the users to continue
    sharing any improvements they make.  As long as large companies
    which use GNU cannot start hoarding it, their use of it does no harm.

So, what steps do you plan to take to ensure this?  You'll have to
have some sort of permanent corporation (in the legal sense) to ensure
this.  I don't want the same thing to happen to gnu as happened to
EMACS: once you pulled out of its support, infinite branching
occurred.  This would kill gnu.

david

Date: Wed 15 Feb 84 00:28:22-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
To: info-gnu%MIT-OZ@MIT-MC.ARPA

I don't mind if some large companies eventually use GNU.
I do wish to prevent them from eventually achieving de facto
ownership of GNU.  For this reason, I do not plan to put the
code I write in the public domain.  I want to permit use of it
on precisely defined terms, which require the users to continue
sharing any improvements they make.  As long as large companies
which use GNU cannot start hoarding it, their use of it does no harm.
-------

Date: Wed 15 Feb 84 00:19-EST
From: Barry Shein <BARRYS%MIT-OZ@MIT-MC.ARPA>
Subject: On the other hand....
To: info-gnu@MIT-OZ


	I was always told that it was IBM that fought
	the idea of patenting software as they were
	afraid that some young snot with a tty would
	corner their market by writing a piece of code
	that worked (as opposed to....) Life just ain't
	that cut and dry. It has been the large companies
	who by and large could not turn out decent software
	that have benefited from public domain or at least
	fuzzily protected software (consider DEC-UNIX,
	DECUS, IBM-SHARE things like TECO, NYU's IBM/ADA
	(lousy but available) etc. etc.) Now consider RSX,
	IBM/OS, PL/I


Return-Path: <efrem@LBL-CSAM>
Received: by lbl-csam.ARPA ; Tue, 14 Feb 84 03:39:54 pst
Date: Tue, 14 Feb 84 03:39:54 pst
From: (Efrem Lipkin [DBG]) efrem@LBL-CSAM
Message-Id: <8402141139.AA17866@lbl-csam.ARPA>
To: +gnu@LBL-CSAM, info-gnu@mit-mc
Subject: yacc and a bit of raving

Sorry to repeat myself, but this message go all hacked up
on the way out.


Bob Corbett told me that he was happy to have anyone use his program
and for the program to be part of Gnu.  He did not know if the university
had any claim on the program or if they cared.  A lot of software is developed
at Berkeley and is available for the price of a tape copy, so I doubt there is
a significant problem.  I think it will be important for Gnu to be, without
question, in the public domain.  Not for any moral reason, but to give it
the best chance at birth.

I do not make the laws and do not believe that laws as laws have any moral
or ethical hold on me, especially when they act to keep the powerful in
control and the weak oppressed, or when they serve to inhibit the flow of
aid, comfort, and information among people, as has been increasingly the
case recently.  Cases where law seem reasonable, though possibly
unnecessary are where they protect people from the strong or the greedy and
dishonest.  Most of these should be covered by simple morals and politeness,
but the complexities of social life make certain ornate protections like
building codes plausible.  Another difficult, but very important case is
controlling exploitation of resources or abuse of native populations from
trees to whales to Amazon Indians.  This again has to do with regulating
the balance between concentrations of power and the general (including
nonhuman) well-being.  This kind of law can be viewed in terms of
socializing morality, a very tricky process, and probably best done some
other way, but an important process.  There is another kind of law I
respect, though it tends to excess.  These are the systems of "standards and
protocols" like traffic laws which are necessary to make some kinds of
large-scale or dangerous processes predictable and manageable by the 
participants.

We are dealing with both the good and bad purposes of the law.  The
intellectual property laws are justified (made legitimate) by claiming to
help individuals get some value from their creativity and thus encourage
creativity for the social good.  There is some truth to this, but their
major significance is in aiding a small number of people to hold a monopoly
on what is actually socially created wealth, the product of which should be
held by society in general.  Inventions are rarely exploited by their
creators (they do not have the money) and no invention is independent of
the whole system of culture, the history of creation, or the contemporary
work of others.  This is way automation is going to be such a problem, it
is a socially created technology the use of which should be "rented" from
the society, but which will be used to avoid such payment, to maximize
profit.  Automation, the mechanical slave, should represent the great
accomplishment of Western Technical Society, but appears to be a major
threat to vast numbers of that society and possibly to the society itself.

The nature of ownership is going to change as more and more of what is
owned becomes increasingly ephemeral and reproduceable.  There is a very
interesting early article on this by Walter Benjamin, called (I think) "The
Work of Art in the Age of Mechanical Reproduction", to be found in the
collection Illuminations.  The recent SONY case was a good example of the
confusion which is on us over ownership of software.  Of course the
classical battle over ownership of natural resources and capital goods is
not going away, though it is getting weird, look at the French and
Spanish "socialist" governments.  But unlike the ownership of goods, the
question of ownership of information & software can not be localized.
What would happen if the Albanians were to massively publish the
source code of Unix?  What is the value of a counterfit dollar in Germany?
Will the rules of ownership collapse or they become increasingly rigid?
What color uniforms will the information police wear?  Why is the open
sharing of information not the same as the sharing of wealth?

Some midnight I'll try and put this in coherent form, but I think it is
important to realize that Gnu is not about Unix [What a strange idea that
someone could own a word!], but about working with a kind of wealth which
like any other wealth takes sweat to create, but unlike anyother kind of
wealth, once it is created there is no need for it to be scarce.  It is 
kept ARTIFICIALLY scarce so someone can make money AND ONLY SO SOMEONE CAN 
MAKE MONEY.  This kind of wealth is no substitute for food and shelter, but
it is a big help in gainning them.  The struggle over this kind of wealth 
will make the next few decades very interesting if all our various
governments are kind enough to let us live through them.

Tune in tomorrow for the story of Baron Rothchild and the Pigeons.

Return-Path: <efrem@LBL-CSAM>
Received: by lbl-csam.ARPA ; Tue, 14 Feb 84 03:17:30 pst
Date: Tue, 14 Feb 84 03:17:30 pst
From: (Efrem Lipkin [DBG]) efrem@LBL-CSAM
Message-Id: <8402141117.AA17802@lbl-csam.ARPA>
To: info-gnu@mit-mc
Subject: repeat of mangled note on parser geneator and ...



Return-Path: <efrem@LBL-CSAM>
Received: by lbl-csam.ARPA ; Mon, 13 Feb 84 23:40:39 pst
Date: Mon, 13 Feb 84 23:40:39 pst
From: (Efrem Lipkin [DBG]) efrem@LBL-CSAM
Message-Id: <8402140740.AA16878@lbl-csam.ARPA>
To: info-gnu@mit-mc
Subject: The author's position on this alleged parser genrator

Bob Corbett told me that he was happy to have anyone use his program
and for the program to be part of Gnu.  He did not know if the university
had any claim on the program or if they cared.  A lot of software is developed
at Berkeley and is available for the price of a tape copy, so I doubt there is
a significant problem.  I think it will be important for Gnu to be in the
public domain

Date: Tue 14 Feb 84 00:00:40-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Why look for reasons to lose?
To: info-gnu%MIT-OZ@MIT-MC.ARPA

When software is written at a university, the author often has a great
deal of power over how it is distibuted unless the university
administration becomes specifically interested in it.  It is nearly
inconceivable that a university would make a belated attempt to claim
ownership on discovering that the author had been sharing it for some
time.  For a free software movement to throw away so many opportunities
is ridiculous.

If you look hard enough, you can find all sorts of reasons
why someone else has legal veto power over your right to use
many piece of "free" software you can think of.  I suspect that
they lose those rights if they don't start claiming them and
enforcing them soon enough and use of the program spreads.
That is the sort of thing I would expect common law to say.

For example, I never asked the MIT administration what they thought
should be done with EMACS; I just started sharing it.  Perhaps
according to the law MIT should have been able to set the terms for
distributing EMACS; perhaps MIT would have decided to sell it.  My
goal was to take it out of their hands.  Hedrick, do you want to stop
using EMACS now that you know this?  I don't think you expect MIT to
sue you any more than I do.

The question, then, is: does one make an effort to inform such
institutions at the critical moment so that they get the chance to
exercize their legal rights to screw everyone else?  Or does one
refrain from informing them so that they miss the chance and can't
cause good people trouble?

Since I believe that hoarding software is immoral and sharing it is a duty,
my conscience clearly directs me to the latter choice.  And that is what
I am going to do.

The only reason to remind them to consider exercizing such rights at
the proper time would be respect for those institutions.  However, if
an institution is inclined to hoard software, that is in itself a
reason it does not deserve respect.  It is a public nuisance and the
first priority is to stop it from hurting people.
-------

Received: from ucbdali.ARPA by UCB-VAX.ARPA (4.22/4.22)
	id AA03634; Mon, 13 Feb 84 19:24:08 pst
Received: by ucbdali.ARPA (4.22/4.22)
	id AA13499; Mon, 13 Feb 84 19:23:30 pst
Date: Mon, 13 Feb 84 19:23:30 pst
From: bh%ucbdali@Berkeley (Brian Harvey)
Message-Id: <8402140323.AA13499@ucbdali.ARPA>
To: info-gnu@mc
Subject: Salt Lake Usenix


Did y'all get the announcement about the Salt Lake City conference in
which gnu is mentioned as a possible discussion topic, under Unix-like
operating systems?

Received: from MIT-MC by MIT-OZ via Chaosnet; 13 Feb 84 20:04-EST
Date: 13 Feb 84 20:04:42 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: Ownership
To: RMS%MIT-OZ@MIT-MC.ARPA
cc: info-gnu%MIT-OZ@MIT-MC.ARPA
In-Reply-To: Message from "RMS%MIT-OZ@MIT-MC.ARPA" of 13 Feb 84 14:31:01 EST

There may be other people involved with Gnu who are concerned not
to violate the law.  Indeed I will be hesitant to be involved, or
even to use the software that results, if I do not have some
assurance that reasonable attempts are taken to operate legally.
-------

Date: Mon 13 Feb 84 14:31:01-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Ownership
To: info-gnu%MIT-OZ@MIT-MC.ARPA

I don't recognize any moral validity in the idea of
ownership of software.

If a friend offers to give me a program if I agree
not to share it, I will probably tell him I don't
want it on those terms and that I will do without it.
This would be for the sake of my relationship with him.
This is what I would do with the individual who wrote
the YACC clone.

With impersonal organizations, since I am sure they have
no right to refuse to share, and that for me to use the stuff
in GNU is morally best if I can succeed in doing so, my only
consideration is whether someone is really likely to sue me.

I expect that the likelihood of being sued by a university is
not all that great, especially if the situation is somewhat unclear.
For example, if they have no idea that the program exists
until years later, by which time dozens of people from many
places have worked on it, then there will be no suit.
The best way to allow such situations to develop is to refrain
from calling a would-be owner's attention to the existence
of anything.

I don't want to have any sort of "submission form"
because part of my goal is to discourage compliance
with and respect for teh authority of bureaucracy.

I do sometimes ask lawyers for advice on the tactical question
of whether Bell could successfully sue me in certain circumstances.
I could conceivably ask similar questions about universities,
but it is only worth while if it seems plausible that a
university would want to sue me.  I think this is unlikely.

I do not believe that compliance with the forms of the law
is a virtue, even though I do sometimes comply when threatened.
I do not want to be guilty of pressuring anyone else to comply.

Meanwhile, I urge all of you not to accept software from other
individuals if they don't want you to share it.  Say to them,
"What you are asking me to do is wrong.  I would enjoy using
that software, but I cannot agree to the price of being a bad
neighbor to everyone else.  If that is the price, I choose to
do without it."
-------

Return-Path: <efrem@LBL-CSAM>
Received: by lbl-csam.ARPA ; Mon, 13 Feb 84 02:52:46 pst
Date: Mon, 13 Feb 84 02:52:46 pst
From: (Efrem Lipkin [DBG]) efrem@LBL-CSAM
Message-Id: <8402131052.AA04214@lbl-csam.ARPA>
To: HEDRICK@RUTGERS.ARPA, efrem", rutgers:"@arpa
Subject: Re: yacc & a friends thinking on gnu
Cc: info-gnu@MIT-MC.ARPA

Thsnks for the note,

The author is pleased to see it in the public domain, but neither
of us knows either the University's position or power in the matter.

I do not think there is enough of a Gnu organization to go hire a lawyer,
but we could pass the hat and create enough formality easily enough,
dangerously easily.

Date: 13 Feb 84 04:34:26 EST
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: Re: yacc & a friends thinking on gnu
To: "(Efrem Lipkin [DBG]) efrem"@LBL-CSAM.ARPA
cc: info-gnu@MIT-MC.ARPA
In-Reply-To: Message from "(Efrem Lipkin [DBG]) efrem@LBL-CSAM" of 13 Feb 84 02:26:01 EST

The status of work done by grad students depends completely upon
University policy.  There is always a student handbook somewhere that
defines this sort of thing.  In general there is almost no work that is
by default in the public domain any more.  One would expect that a
University would either retain proprietary rights for itself, or say
that a student owns his own work.  In neither case does this make
software public domain. The University or the student would have to make
that decision. There is a common misconception that work supported by
tax dollars is in the public domain.  Although I happen to think this
should be true, it isn't. Each grant has in it provisions specifying who
retains what rights.  Most grants these days allow the University to
retain all proprietary rights, except that the Government gets a
non-exclusive license to use the results.  It is then up to the
University's policies.

If we are going to be careful about the public domainedness of our
software (and we should be), then you need to check a couple of things
before using this yacc-equivalent:

  - Did its author either declare it to be in the public domain or
	specifically authorize its use as part of Gnu?  Distribution
	through DECUS specifically declares something to be in the
	public domain.  Giving a copy to a friend does not, although
	careful authors will specify the status of something when
	giving it away.

  - Did the author have the right to do what he did, according to
	his University's policies, and its license agreements with
	third parties?

It would probably be a good idea to have a standard submittal form
such as the one used by DECUS.  This would formally give Gnu the
right to distribute the software, and certify that the author had
the right to do this.  Even with this, you might want to do at least
some independent checking.  Is there any Gnu organization that could
employ a lawyer to do this right?
-------

Return-Path: <efrem@LBL-CSAM>
Received: by lbl-csam.ARPA ; Sun, 12 Feb 84 23:26:01 pst
Date: Sun, 12 Feb 84 23:26:01 pst
From: (Efrem Lipkin [DBG]) efrem@LBL-CSAM
Message-Id: <8402130726.AA03693@lbl-csam.ARPA>
To: info-gnu@mit-mc
Subject: yacc & a friends thinking on gnu


Here are some thoughts on gnu and the relationship between energy
and existence from Mark Szpokoswski a friend in Halifax, Nova Scotia
for whom I've much respect.  But first, some busines:

	Are we free to include software which was developed as part
	of someones graduate research at University?  I've have been
	given a parser generator, authored by Bob Corbett at UCB.  Basically
	compatible with YACC he claims it executes twice as fast as YACC,
	produces a faster parser, and does better error recovery.
	I'll give it a try sometime soon.  Can someone give me solid
	opinion on the situation?

			-- Efrem

From dreacad!dalcs!amivax!mark@nrl-aic Tue Jan 24 05:15:58 1984
Date: 24 Jan 1984 08:05:49-PST

Gnu comments:

-- Price of software tends to approach price of distribution. 
This seems to be the case with books.  The implication is that
authors of best-selling software will do well, whereas most
others will have to support themselves otherwise, or live rather
poorly.  The irony is that it takes a lot of energy to develop
software or to create something, while it takes much less to
reproduce it (or a different kind of energy).  Stallman seems to
accept it:  you can charge for distribution but not for the
source code itself.

-- Related note:  Canadian Writers' federation is lobbying the
Fed. Gov't to have libraries provide them royalties for their
books, perhaps proportional to the extent they are borrowed.

-- The basic contradiction being addressed by the gnu discussion
might be between, on the one hand, the desireability for free
exchange of ideas and software for purposes of research, and, on
the other hand, the need to protect trade secrets and proprietary
information for purposes of commerce.  

-- It still seems that the best (and maybe only) model to use is
that of evolutionary biology, but (1) the model itself is not
that clear, and (2) how to apply it is a difficult question.  The
capitalist version is "survival of the fittest"; the socialist is
perhaps "coevolution" (altho such broad strokes are painfully
gross).  "Source code" is equivalent of genetic information; you
need source code to develop further software.  There's something
exciting about free gnu ("free as air") which creates an
environment for further software advances, although again, as
many of the anti-people suggest, diversity would lead to it being
somewhat "wobbly gnu" (!).  

-- The crux of the issue has not really been addressed, as
evidenced by the fact of our Balkan dancer's "request for
donations":  how are the gnu-ons to survive?  None of us have
really successfully dealt with this.  

-- On the one hand life doesn't seem to really care; individuals
live and die.  However, at the level we are concerned about,
which is that of individuals' life spans, there are supportive
and caring forms.  E.g., "Family bond" and "clans",...

-- I'm all for wobbly gnu as an interesting and already legendary
experiment; the issues around cm are similar if not identical. 
RMS should be toasted at Callahan's Cross-Time Saloon.

-- (are gnu-ons the ones who keep gnu together?)

-- Mark




Received: from MIT-LISPM-5 by MIT-OZ via Chaosnet; 8 Feb 84 04:12-EST
Date: Wednesday, 8 February 1984, 04:14-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Anyone have floating point routines?
To: info-gnu%MIT-OZ@MIT-MC.ARPA

I need some floating point routines in 68000 assembler language.
Or, if I can't have those, I need floating point routines in
any assembler language that I can get them in.
If you can find me either one, please tell me.

Date: 2 February 1984 01:06 EST
From: David Vinayak Wallace <GUMBY @ MIT-MC>
Subject: BDS c utilities
To: INFO-GNU @ MIT-MC

1> there exists a utility to read cp/m floppies onto a vax (an thence to tar)
2> A lot of BDS-c software lives on SIMTEL-20 on the arpanet " "       " "
3> Youcould call leor (:whois LEOR) and ask him if he has the utilities online

david

Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.22/4.21)
	id AA03622; Wed, 1 Feb 84 21:14:51 pst
Received: by ucbernie.ARPA (4.22/4.19)
	id AA01975; Wed, 1 Feb 84 21:10:16 pst
Date: Wed, 1 Feb 84 21:10:16 pst
From: phr%ucbernie@Berkeley (Paul Rubin)
Message-Id: <8402020510.AA01975@ucbernie.ARPA>
To: info-gnu@mit-mc
Subject: another source of PD software

I am told that the BDS C User's Group has written PD versions of many of
the Unix utilities in BDS C, and translated/improved some of Kernighan
and Plauger's Software Tools.  Unfortunately BDS C is a little bit
different from standard C and the programs are distributed on floppy
discs (although there is an RCPM system somewhere in Pennsylvania from
which the programs could be slurped over the phone).  Also there may
be some dependencies on (blech) CP/M.  There is something like 1 MByte
of source code available from them.  Their address is:

	BDS C User's Group
	PO Box 287
	Yates Center, Kansas  66783
	(316) 625-3554

Does anyone know more about this?

paul

Date: Sun 22 Jan 84 03:20:53-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Progress has occurred
To: info-gnu%MIT-OZ@MIT-MC.ARPA

While in California I got a copy of the Livermore extended Pascal compiler.
It is extended enough to be more powerful than C.  On the other hand,
the 68000 code generator was only half written.  I managed to do a little
work on it there.  I expect it will take only a month or so to finish that
and do the C front end, which I expect can use the same tree structure
representation that Pascal uses, starting from the time I get a convenient
Vax to work on.
-------

Date: Mon 2 Jan 84 04:44:18-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: [Howard Alt <alt@aids-unix>: Announcement of meeting.]
To: info-gnu@MIT-MC


		West Coast Gnu Meeting

Time: 2:00pm
Date: Saturday, January 7
Place: Advanced Information and Decision Systems.
	201 San Antonio Circle, Suite 286
	Mountain View, Calif
	94040
Phone: (415) 941-3912
Read The Notes.

		THIS MAP IS NOT TO SCALE!!!
--------------------------------+----------------------------
El Camino Real			|
				|
				|
				|
				|  
California Ave			| (no left turn onto cailf from s.a.)
--------------------------------+---------------------------
				| /--\
			|-----|	|/   /
		AI&DS ->|-----|	|   /   <- San Antonio Circle
		----------|-----|--/
Central Expressway (alma)	|
--------------------------------|---------------------------------
				|
				|
				|			(pseudo north)	N
				|
				|					|
US 101				|					|
================================|===============================       \ /
<-- San Jose			|		San Francisco -->       V
				|
				^ San Antonio Road.


Notes: 
1) AI&DS is in the Old Mill Office Center.  We are Suite 286.

		/--------\
		|	 |
		|xx	 |
		\--------/
We are in the corner marked with x's  (same orientation as the map).
If you come to a locked door, try another.  We will have one unlocked.

2) Since you can't take a left turn onto california from san antonio,
you need to go around and under.  San Antonio crosses over alma, some
railroad tracks, and san antonio circle.  Just follow the signs to
the Old Mill Shopping Mall.  We are to the West of the Mall.  

		Good Luck,
			Howard Alt.
-------

Date: Fri 30 Dec 83 01:18:05-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: You can use the standard subroutine libraries
To: info-gnu@MIT-MC

In writing programs for GNU, feel free to make use of all
the standard subroutine libraries.  Work is already
being done to implement duplicates of those libraries.
-------

Date: Wed 28 Dec 83 21:17:13-EST
From: Rich $alz <DCB.TECH%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Task List for GNU
To: RMS%MIT-OZ@MIT-MC.ARPA
cc: info-gnu@MIT-MC
In-Reply-To: Message from "Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>" of Thu 22 Dec 83 10:41:47-EST

I have a version of make that is much quicker, and somewhat smaller.
It is currently a revision of make, but am in the process of writing
it from scratch.  It should be releaseable in a month or so, as a public-
anyone who'se interested in the unix(tm)-dependent one now can
contact me.
	/rich$alz
-------

Date: Fri 23 Dec 83 20:26:58-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Day for meeting
To: info-gnu@MIT-MC

How does Saturday Jan 7 sound for the meeting?
-------

Date: 22 Dec 1983 17:50:57-PST
From: Andy Cromarty <andy@aids-unix>
To: info-gnu@mit-mc
Subject: re: West Coast GNU Meeting

  We may be able to host the meeting at AI&DS if it is held in the
evening.  If this is desirable (and if the meeting is indeed going
to be held during the evening), I will check on it.

					asc

Received: from MIT-LISPM-2 by MIT-OZ via Chaosnet; 22 Dec 83 14:18-EST
Date: Thursday, 22 December 1983, 14:18-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: West Coast GNU Meeting
To: info-gnu at MIT-MC

I will be in the Palo Alto or Berkeley area from January 6 to January 15.
I'd like to set up a meeting for GNU enthusiasts during that time.
I'd expect between ten and twenty people to be there.

Can anyone offer a place to hold such a meeting?
 (I have a friend in Santa Cruz who might be able to offer a place,
  but perhaps that is inconveniently far away.  Is it?
  I'm not certain that he can offer his place, so other offers
  are still requested in any case.)

Does anyone have preferences for which day to hold it?

Date: Thu 22 Dec 83 10:35-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Task List for GNU
To: info-gnu@MIT-MC

I now have a list of the high priority tasks for GNU
which are not being worked on.  If you would like to
contribute to GNU, please look through these for
something you would like to work on.  While any useful
program that runs on Unix would be appreciated, these
are what will have to be done by me (after the compiler)
if nobody else does them first.  Let me know what you
are interested in working on.  Eventually I will send
a list of who is doing what back to INFO-GNU.

-*-Text-*-

Programs needed for GNU:

1. Large projects

* a debugger (like adb, sdb, or dbx)
 Precise compatibility with an existing debugger is not required.

* awk (pattern processing language)

* bc and dc (arbitrary precision arithmetic calculator)

* diff3 (compare three files)

* ed (standard stupid text editor)
 You can convert the Software Tools editor from Ratfor to C.
 Comparatively few additional changes would be needed.

* ls (list directory)
 This can start small.

* plot (graphics filters)

* tar (tape archiver)

* make (invoke compilers on changed files)

* sh (shell)
 A simple shell is available, but it needs much extension,
 especially with regard to programability.


2. Small projects.

* cat (concatenate files)

* cmp (compare files)

* cp (copy files)

* date (print and set the date)

* dd (convert and copy files)

* find (find files)

* ln (add name to file)

* mkdir (create a directory)

* mv (move or rename files)

* pr (print file)
 A stripped-down version of this can be found in the
 Software Tools tape.  That may or may not give
 a noticeable amount of help.

* rm (unlink files)

* spline (interpolate curves)
 I can give you a three-page long Lisp program that you
 can get the algorithm from.  Given that, this is not very hard.

* sum (count blocks and checksum file)

* tee (split pipes)

* tr (translate characters)
 Can be done by translating a Software Tools program
 from Ratfor to C.

* who (list users)


Many other utilities could also use being written
but are lower priority.  If you feel like doing some other utility,
that is fine, but check with me first, since some of the programs
not on this list are omitted because I already have one.

Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 15 Dec 83 18:13-EST
Date: Thursday, 15 December 1983, 18:16-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Good Gnus
To: info-gnu at MIT-MC

The S-1 project at Livermore has written a portable Pascal compiler,
which generates code for Vexes, 68000's and (maybe not quite yet) 16000's.
They are willing to let GNU use it and redistribute it.

I hear that it generates very good code for Vexes at least,
so it should be able to do so for other machines if that is given some attention.

From the way Jeff Broughton described the compiler, it sounds like
making a C front end for it is no harder than writing a front end
for the Amsterdam Compiler Kit: the C front end must output "instructions"
for an abstract machine, and it need not worry about optimizations
except for constant folding.

So we still need to write a C front end, and also a Fortran front end
would be nice.


On Tuesday I spoke to Jon Sieber (jon@mit-vax), the author of Trix.  He
says that Trix will be ready for real use on a network of 68000 machines
in a few weeks.  Trix is based on message passing between tasks, and
the file system is not in the kernel.  It is not anything like Unix
internally.  Currently Trix supports Unix system calls except for
Fork, which it does differently because John thinks Unix Fork is done
stupidly (I agree).  It should not be hard to provide a compatible Fork,
though.  He is looking forward to seeing Trix used in GNU.

Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 5 Dec 83 16:37-EST
Date: Monday, 5 December 3883, 16:35-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: It's official: compiler is task #1.
To: info-gnu at MIT-MC

I could use a few more volunteers to work on the compiler kit for GNU.
This is the most important task for the project at the beginning.

Due to the nature of the task itself, these must be people who are
fairly experienced.  Also, it is necessary for you to make a commitment
to finish whatever part of the compiler you undertake.

Send me mail if you want to join.

Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 5 Dec 83 16:25-EST
Date: Monday, 5 December 3883, 16:23-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Cheap is not almost as good as free.
To: decvax!mcvax!vu44!ast at UCB-VAX.ARPA
CC: info-gnu at MIT-MC

The goal of GNU is to make available a complete general-purpose software
system, which has no restrictions to prevent people from making full
cooperative use of it.  This means they have to be free to redistribute
it and free to change it.

Simply reducing the price does not accomplish this.  I do not think a
high price is bad, because there is nothing bad per se about a
programmer making more money.  Paying the price is not the worst problem
about software that is sold.  Worse problems are the artificially
imposed waste and the uncooperative attitude that owners choose and
licensees are forced into.  Competition may lower the price but it does
not eliminate these problems.  GNU can do it.

I sympathize with the financial need of your university.  It is sad that
you have chosen to try to alleviate it with means that will generate
more need elsewhere than it dispels near you (when compared with your
maximally productive alternative).  Can you not see that if everyone
in every field acts that way your university will be poorer than before?
We are all in the same boat.

I must decline your offer to license the compiler to me, because a
licensed compiler cannot be part of GNU.  It could only be used for
bootstrapping, and for that any C compiler would do equally well.  I
personally expect to obtain the use of one without signing any license
agreement, since it will be on a computer that I do not own.  I do not
expect any other GNU developers will be interested either, though
perhaps it would be useful for someone to play with your compilers and
look at the code they generate so as to better design our own.

For the same reason, we would not be interested in joining you to
package the kernel and utilities and sell them.  (I am assuming that
your use of the word "sell" implies restricting redistribution.)  That
would not advance one jot toward the goal of GNU.

If you choose to make the kernel you are writing available for free
redistribution, we may use it.  There seems to be already a kernel
written at MIT which is available free, so a kernel will not in any case
be among our first projects.  Perhaps we will want to replace something
such as the file system or the scheduler in the kernel that exists, or
add certain features.  Or we could switch to using your kernel if it is
better.

In fact, the main piece of the system that we cannot get free seems to
be the compilers.  It is with regret that we are, therefore, now gearing
up to write a compiler kit, along the same general lines as yours.  Work
on the machine-independent assembler is already under weigh, and I have
three additional volunteers eager to work with on the compiler proper
together with me.

I would like to be able to avoid duplication of effort with you.
But this can be done only with programs you make free.
If you do not make a program free, a duplication of your effort
sooner or later (probably sooner) is inevitable.
It is best if I duplicate it soon, because my duplicate will
be free, and then nobody else will have to duplicate it again.

						Hoping you will reconsider,
						Richard M. Stallman
						545 Tech Square, rm 913
						Cambridge, MA 02139

You may be able to reply to me as  mcvax!decvax!berkeley!rms@mit-mc
if your mailers give @ higher binding power than !.

Date: 4 Dec 1983 17:27:58-EST
From: allegra!utcsrgv!peterr at mit-vax
To: allegra^mit-vax^info-gnu@mit-mc
Subject: QNX/Thoth

To: allegra!mit-vax!Gumby@MIT-MC, info-gnu@MIT-MC

Yes, QNX is based internally on Thoth, a message passing OS built at
U. Waterloo.  Thoth passed fixed length messages between processes using
a synchronous send/receive/reply protocol (A sends to B and waits,  B
receives, B does as much as it wishes, B replies to A, letting A run
again).  QNX certainly uses this protocol.  They may have added variable
length messages.  Thoth allows groups of processes (called "teams") to
share an address space.  Details of Thoth may be found in a book by
David Cheriton, called "Thoth: A Message-Passing OS" (or something like
that) published by North-Holland.




Date: Sun, 4 Dec 83 03:27:03 pst
From: efrem@LBL-CSAM (Efrem Lipkin)
Return-Path: <efrem@LBL-CSAM>
Message-Id: <8312041127.AA12501@lbl-csam.ARPA>
Received: by lbl-csam.ARPA ; Sun, 4 Dec 83 03:27:03 pst
To: RMS%MIT-OZ@MIT-MC.ARPA, info-gnu@MIT-MC
Subject: Re:  Cheap Computers for GNU hackers?

Dear Richard,

Would you kindly send a copy of Jan Kok's letter to me:

Efrem Lipkin
1811 Ward Street
Berkeley, CA 94703

I am recently returned from North Africa and trying to figure out what
efforts I should make for your project. Has there been any kind of
specification written?  Any allocation of work?  A lis tof requirements.

I would rather not see Unix duplicated, I consider it a good system only 
compared to IBM's OS.  Good programmers, but a lack of long-ranged vision.
It seems to me that the goal should be an excellent system with the useful
feature of running object programs from some very popular flavor of Unix.

Luck, Efrem


Date: 4 Dec 1983 04:41:17-EST
From: evan at mitccc
To: Gumby@mit-mc, info-gnu@mit-mc
Subject: Thoth
Cc: bnh@mitccc, gyro@mitccc

	Mark of the Unicorn owns a copy of QNX, and I have played with it
it is largely awfull, but that may just be because it was hacked up to be
small enough to fit on an IBM PC. Thoth itself may be just fine.


	You, David, may be able to convince Scott to let you play with
MOTU's QNX, so you can judge for yourself. As for those out in net-land,
keep those cards and letters coming.


					---Evan

Date: Sunday, 4 December 1983, 04:01-EST
From: David Vinayak Wallace <Gumby at MIT-MC>
Subject: Thoth
To: info-gnu at MIT-MC

Has anybody seen this thing?

Date: Wed, 30-Nov-83 10:49:00 EST
From: Cargo.PD%hi-multics@sri-unix.UUCP
To: net.micro
Subject: QNX

QNX is based internally (so I have been given to understand) on THOTH,
the University of Waterloo portable operating system. There are some
technical reports available from Waterloo and an article about THOTH in
Communications of the ACM from some time back, if you are interested in
(possibly related) internal characteristics.

Date: 8 Nov 1983 18:38:43-EST
From: rmc@CCA-UNIX (Mark Chilenskas)
To: rms@mit-mc
Subject: GNU
Redistributed-to: info-gnu at mc
Redistributed-by: Richard M. Stallman <RMS at MIT-OZ>
Redistributed-date: Saturday, 3 December 3883, 05:55-EST

    Whelp, i was originally worried about your motivation/rationalness when we 
talked in Black Forest.  I am no more enamored of communism than i am of 
christianity (small c in each case is intentional) because i see some people 
as being more constructive, creative, helpful, what have you, and i think they 
should have some chance at reward.  (Note that this is distinct from Communism 
and Christianity, which are merely forms for impressing ideas on people with a 
different beaurocracy).  However you said that yes, people can charge for 
distribution, support, "hand-holding", custom software, etc.  The idea is 
"just" to encourage sharing.

    I could not agree more.

    I will not leave CCA at this point, partially because it provides a good 
salary, interesting work, and an environment closer to the AI lab one you
describe than you would at first expect.  Thus i can enjoy what i am doing and
help you and not stretch your financial resources.  However i am interested in
aiding and abetting the GNU project.  I have started my own company, Koshchei
Associates, with the intent of doing some amount of custom work and doing some
language work, mostly in very high level applicative and object-oriented
languages.  I intend to see how far you can push a mediocre 8086 toward
providing an equational language such as KRC or FFP (especially like Guttag's
FFP with abstract data types added).  I want to play with a truly object
oriented system.  Since this would be on a "hobby" basis, nothing would be
available in the immediate future, but that's ok.  The creativity is the
point, and i don't expect to get monetarily rich on freeware. 

    However, on the way, i would need to produce some number of "UNIX utility" 
like things.  A very early effort would be LEX, or something very like it.  
A functional programming support package, including a parser, garbage 
collector, object manager for secondary storage...  A good macro package, 
starting with facilities like m4 on UNIX.  These things will be worked on 
soon, and hopefully some of them will be available this year.  They will be 
made available to GNU and distributed by me under similar restrictions.  I had 
sort of intended to use FORTH, MACRO, LISP and Modula II to produce this stuph 
(depending upon what functionality i needed for the tool).  Based on your 
writings, i will also get a C compiler and convert some of the things for you. 
Others you will get in my crazy languages, and if you think the tool worth it, 
will rewrite the thing specifically for GNU.

    Incidentally, i think you should support FORTH or some stack oriented 
language.  They are very efficient on micros, and provide a lot of the user
mungability that you prefer.  Yup, i like LISP a whole lot, but NIL takes up 
almost too much space on a VAX.  How do i fit it into a 64k or 128k micro?  
(yes, i know McCarthy LISPS did, but that excluded a lot of the environment 
that makes LISP a winner.  In a stack threaded language you lose for 
uniformity of representation but gain some in space, which is the biggest 
problem here i think).  I am doing a FORTH based on fig-FORTH (another example 
of software sharing which is blossoming!) and will make sure it runs on GNU.

    Don't lock yourself into the 68000 / 16032 market.  These machines will 
be EXPENSIVE, the majority of the people will be running CPM on Intel 80xxx
type things (look at the number of IBM PC's available).  Yup, i will help make
sure GNU things will run on my NEC APC if you are willing occasionally to talk
to me about reasonable ways to subset the functionality.  I don't believe a
poor 8086 can keep up with a real virtual memory system.   People running an 
IBM kludge are worse off than i am, because the 8088 does single byte fetches 
instead of 16 bit fetches.  But Lauren Weinstein came close to UNIX with MARC, 
so we should be able to do SOMETHING.

    You have touched something in me that has been waiting for a stimulus for 
quite some time now.  I feel inspired.  There must be others as well.  
Richard, this thing will work.

    					v
    					Z


Received: from MIT-MC by MIT-OZ via Chaosnet; 2 Dec 83 05:50-EST
Date: Friday,  2 Dec 1983 02:51-PST
To: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Re: Cheap Computers for GNU hackers?
From: Steve Hartwell <hartwell@Shasta>
Redistributed-to: info-gnu at mc
Redistributed-by: Richard M. Stallman <RMS at MIT-OZ>
Redistributed-date: Saturday, 3 December 3883, 05:53-EST

Could you add me to the info-gnu list at mit-mc, and also
send me snail mail a copy of the letter by Jan Kok about the 68K
system.

I would be interested in contributing in a significant way to GNU,
both in kernel design and utility development & support.  This is
provided that I feel that the design is rational and well organized,
and that design decisions are not made by only a few and do not contain
arbitrary design preferences of a subset of the likely GNU users.
In particular, I do not feel that a kernel written in LISP is a rational
design.

My snail address is:
    Steven Hartwell
    ERL 407
    Stanford, California 94305

I am a system hack for a gaggle of vaxen at Stanford.

Date: Saturday, 3 December 3883, 05:45-EST
From: Richard M. Stallman <RMS at MIT-OZ>
Subject: [Sjobrg.Bandy at MIT-OZ: Re: Assembler]
To: info-gnu at mc

Progress is occurring, on the machine-independent assembler.

From: Andrew Scott Beals <Sjobrg.Bandy@MIT-OZ>
Subject: Re: Assembler

i should be generating code (68000,  as i can trivially test it) soon.
withing the next couple weeks.

Received: from MIT-LISPM-18 by MIT-OZ via Chaosnet; 1 Dec 83 09:07-EST
Date: Thursday, 1 December 3883, 09:13-EST
From: Richard M. Stallman <RMS%MIT-OZ@MIT-MC.ARPA>
Subject: Cheap Computers for GNU hackers?
To: info-gnu at MIT-MC

Jan Kok, a hardware hacker, believes he can design a 68000 system
which is sufficient to run GNU and could be manufactured for $3000
(terminal not included).  He would like to offer them approximately
at cost to anyone who contributes significantly to GNU.
He thinks that the design and debugging will take a year of his
spare time work, but is asking for interested people to help out
and possibly speed that up.  Once designed, the computers will
be manufactured by a company he deals with.

He has sent me a letter which describes some of the choices he is facing
and asking for the programmers' and users' preferences.  It is too long
to type in.  If you are near by and would like to see it, come and see me.
If you are distant and would seriously like to look at it, I can
snail mail you a copy of it.

Date: 19 Nov 83 07:34:00 EST (Sat)
From: rej@Cornell (Ralph Johnson)
Subject: Ingress
Message-Id: <8311191234.AA04081@GVAX.CORNELL>
Received: by GVAX.CORNELL (3.320/3.14)
	id AA04081; 19 Nov 83 07:34:00 EST (Sat)
To: info-gnu@mit-mc, rminnich%udel-eecis1.udeecis@udel-ee

One of the source files for Ingress carried the declaration that it was
entirely public domain, and anybody could do anything with it that they
wanted.  Ingress was developed using government funds, so this is standard
procedure.  You have as much right to do what you want with it as the
original authors.  Some of them have gone in to business (I forget their
name) and are selling an improved version of Ingress.  Naturally, their
improvements are their own property, but the original Ingress is not.
You could compete against them, if you wanted, but they have the advantage
of having studied Ingress for many, many years.

A friend of mine ported the PD version of Ingress to a 68000. He only had
to change four or five lines, although it took him a while to find them.
He has since observed the commercial version of Ingress for te 68000, and
it seems identical (same features, same timings).  The VAX version of
Ingress has been spiffed up quite a bit, but the same attention has
apparantly not been spent on the 68000 version.

	Ralph Johnson

Date:     Fri, 18 Nov 83 9:12:06 EST
From:     Ron Minnich <rminnich%udel-eecis1.udeecis@udel-ee.arpa>
To:       info-gnu@mit-mc.arpa
Subject:  cards and letters; ingress

   thanks for all our cards and letters. I am still not yet getting
info-gnu, but it is nice to know that ATT did not shut it down.
   I do not know where the discussion has been going lately, but 
earlier someone ( I do not remember exactly who) stated that Ingress
was PD. Does that mean, for example, that I can transfer it to my 
home Unix system, compile it, use it, and give it to other people?
(No charge from me, of course). 
   ron

Date:     Thu, 17 Nov 83 8:59:12 EST
From:     Ron Minnich <rminnich%udel-eecis1.udeecis@udel-ee.arpa>
To:       info-gnu%mit-oz@mit-mc.arpa
Subject:  strange goings-on

   Someone please let me know if this message makes it.
When i send to info-gnu, the only response I get back is a complaint
from mit-mc that info-gnu does not exist. I NEVER get my message back
except as part of an error message. Are the rest of you getting 
info-gnu? Could someone have it remailed to me? I am not sure what
the heck is going on, but I did get messages back from people who
saw my earlier 'testing' message, so my mail must be going somewhere...
   aarrghh.
ron

Date: Wed 16 Nov 83 23:58:50-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Status of Gosling's EMACS.
To: info-gnu@MIT-MC

Megatest and Unipress disagree on whether Megatest can give out EMACS.
You are faced with the choice of believing Metagest's position or Unipress's position.
It may well be that neither one is clearly right or wrong;
in that case, I think one is wiser to adopt Megatest's position
and cheerfully accept a copy, and less wise to accept Unipress's
position and suffer on their terms.
-------

Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.21/4.15)
	id AA01160; Wed, 16 Nov 83 01:34:11 pst
Received: by ucbernie.ARPA (4.16/4.13)
	id AA07266; Tue, 15 Nov 83 17:56:27 pst
Date: Tue, 15 Nov 83 17:56:27 pst
From: phr%ucbernie@Berkeley (Paul Rubin)
Message-Id: <8311160156.AA07266@ucbernie.ARPA>
To: info-gnu@mit-mc
Subject: PD status of Gosling's EMACS

I remember even the early, free versions of this program had a copyright
notice which said something like "You are free to use this program on your
own machines, but you are not free to redistribute it.  If you know someone
who wants a copy, refer them to the author."  So it sounds like Gosling's
EMACS never was PD; it was more like one of those "90-day-free-trial"
pitches except the users weren't told until they'd found lots of bugs for
him.  I remember the Unipress announcment said something like "It's a
shame we have to market this program, but it's too good to waste on the
public domain" - the translation is left to the reader.

Date:     Wed, 16 Nov 83 14:11:59 EST
From:     Ron Minnich <rminnich%udel-eecis1.udeecis@udel-ee.arpa>
To:       info-gnu@mit-mc.arpa
Subject:  testing

   Does this list still exist? just checking.
ron

Date:     Wed, 16 Nov 83 8:59:51 EST
From:     Ron Minnich <rminnich%udel-eecis1.udeecis@udel-ee.arpa>
To:       info-gnu%mit-oz@mit-mc.arpa
Subject:  just checking

   I wanted to see if this list was still alive, and/or I was still on
it.
   ron

Date:     Mon, 7 Nov 83 9:21:57 EST
From:     Ron Minnich <rminnich%udel-eecis1.udeecis@udel-ee.arpa>
To:       info-gnu%mit-oz@mit-mc.arpa
Subject:  PD software

   Here we go again.
   (most seen on info-gnu). I am trying to keep a list.
   Do we need to set up a repository somewhere? People could
   mail in their software, and would have access to other's
   contributions. Much like a public library.
   Software                                      Contact
   --------                                      -------

LLAMA, a yacc-like parser generator             Paul Rubin

Fen Labalme's latest version of EMACS              ??

curses-like package from Cornell                   ??

Software Tools from Debbie Scherer                 ??
et al. at Lawrence Livermore

All of Wirth's Modula-2 compilers                  ??

The Uppsala lisp interpreter,                   Ron Minnich
written in Fortran, which needs to
be translated to C.
(Its pretty good).

Most of 4.2BSD                                     ??
			   (anything else???)

ron

Date: Fri 4 Nov 83 21:32:27-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Gosling's
To: info-gnu@MIT-MC

Fen Labalme says that he has done a lot of work on his versions
of originally-Gosling's-emacs, and that it is as good as Unipress's version,
as well as free.  So people should just contact him about it rather
than hassle with Gosling.
-------

Received: by ucbvax.ARPA (4.16/4.13)
	id AA01575; Fri, 4 Nov 83 18:07:06 pst
Date: 4 Nov 83 15:06:46 EST (Fri)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: PD software
Message-Id: <8311042006.AA10085@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA10085; 4 Nov 83 15:06:46 EST (Fri)
To: info-gnu@mit-mc.ARPA

the VU kit is not PD at all.

Gosling's latest EMACS isn't either.  The latest is owned by (who the
heck is it - UniPress?)  The last one Gosling put out before he sold
it, however, is still PD (I think).  You might have trouble getting
Gosling to sign a release, however.

In addition, much of what's on 4.2BSD is PD.  I don't have a tape or
list yet so I can't make a wholesale claim.

MERT and UNIX/RT are different versions of the same system - I think
MERT is the older name.  Neither caught on much outside of a certain
specialized community.

	Mark

Date:     Fri, 4 Nov 83 9:48:19 EST
From:     Ron Minnich <rminnich%udel-eecis1.udeecis@udel-ee.arpa>
To:       info-gnu%mit-oz@mit-mc.arpa
Subject:  PD software, terminals

   Here is what I have seen go by that may or may not be Public Domain.
   (most seen on info-gnu). I am trying to keep a list.
   LLAMA, a yacc-like parser generator
   Much of the VU compiler kit, but for the pcc portion
   Gosling's latest version of EMACS
   a curses-like package from Cornell
   All of Software Tools from Debbie Scherer et al. at Lawrence Livermore
			(or Lawrence Berkeley, I forget which)
   All of Wirth's Modula-2 compilers (I threw this in for kicks)
   The Uppsala lisp interpreter, written in Fortran, which needs to
     be translated to C.
   (anything else???)

   Maybe we should start a mailing list called debates-gnu. GNU has
or should have one simple, well-defined albeit dull and boring goal:
providing a Unix-Compatible set of tools and kernel. Any deviation 
will foment debate and delay. The best terminal management system
I've ever seen ran on Burroughs machines, but I am not about to suggest
adopting it for GNU, because it just would not be appropriate. We know
a lot about Un*x and its applications and I think we need to concentrate
on the task at hand. Otherwise we risk seeing the whole idea die in 
endless debate.
ron
P.S. Howard, when you mention Un*x RT, did you mean MERT? A friend
of mine at Indian Hill tells me that system was a real loser, 
unfortunately.  I say unfortunately because in BSTJ
it sounded pretty neat. oh, well.

Date: 3 Nov 83 18:44:59 PST (Thu)
From: Howard Alt <alt@aids-unix>
Subject: Re:  terminal control
Message-Id: <8311040244.AA17315@aids-unix.ARPA>
Received: by aids-unix.ARPA (3.326/3.14)
To: cbosgd!mark@Berkeley, info-gnu@mit-mc.ARPA, @, aids-unix@aids-unix

Clearly, you want to have one process taking care of all the output
that goes to your terminal.  

The way to do this is to have one process for each terminal
that keeps track of what every other process is sending to the tty.
There should be some clever windowing mechinism that pops up a 
window if a some random process writes to your screen....  of course,
the writing process should be able to exert some control over the window
that gets popped up for it, and do arbitrary cursor movement within
the window, etc.  This would make a lot of software much simpler.

The two ways that I can think  of implementing this are:
1) have a 'driver process'.  A driver process would be forked off
by login.  For a process to write to a terminal, the driver process
would have to be running.  Obviously, the driver would read the
terminal file from disk, etc, etc.

2) have a system call that allows a process to snarf up every char
sent to a particular device.  Have a shell that uses this call.


Both 1 and 2 require another thing to allow a process to bypass the
'snarfing'.  1 in the case of the getty, login and 2 in the case
of the shell.

2 has the advantage of not forcing the poor user into dealing with
the window system, if he dosn't want to... he could use any shell, or
any program as long as the window shell (wsh?) wasn't beeing used.


				Howard.

Received: by ucbvax.ARPA (4.16/4.13)
	id AA09313; Thu, 3 Nov 83 17:39:13 pst
Date: 3 Nov 83 16:41:21 EST (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: terminal control
Message-Id: <8311032141.AA02326@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA02326; 3 Nov 83 16:41:21 EST (Thu)
To: info-gnu@mit-mc.ARPA

It's clear you don't want to keep the whole terminfo database in the kernel.
However, you can keep it in a regular disk file and implement an ioctl that
passes a table (conveniently formatted for the kernel), in effect saying
"this is the kind of terminal I am on, and here's how to use it".

I am strongly opposed to the "terminal driver" approach because of the
software maintenence considerations.  When you have to support 150 terminals
with perhaps 300 names (when you take user preferences into account),
you don't want to have 300 copies of the routine that figures out how to
get the cursor from here to there, or how to use insert line, or how to
deal with magic cookie braindamage.  There is a lot of commonality in
terminals, even if there is also a lot of difference, and it's wasteful
to have to code optimizations separately for each terminal.

I should also point out that if you always have a screen program doing
screen optimizations for regular tty output, the terminal will "feel"
very different.  Some will undoubtedly argue that this is "not UNIX"
or is "against the UNIX philosophy".  Bear this in mind when making the
decision.

	Mark

Received: by ucbvax.ARPA (4.16/4.13)
	id AA09335; Thu, 3 Nov 83 17:40:51 pst
Date: 3 Nov 83 16:43:28 EST (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: VU compiler kit, old versions
Message-Id: <8311032143.AA02361@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA02361; 3 Nov 83 16:43:28 EST (Thu)
To: info-gnu@mit-mc.ARPA

There was something before which was PD.  It only handled Pascal, and only
for the PDP-11.  However, the flavor was very similar to this one, and
no doubt it's a predecessor.  It had umpteen stages in a pipeline,
going into EM1 code and either interpreting that or generating code from it.

	Mark

Received: by ucbvax.ARPA (4.16/4.13)
	id AA08953; Thu, 3 Nov 83 17:16:35 pst
Date: 3 Nov 83 09:45:45 EST (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: more from Andy Tanenbaum
Message-Id: <8311031445.AA17146@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA17146; 3 Nov 83 09:45:45 EST (Thu)
To: info-gnu@mit-mc.ARPA


>From mcvax!vu44!ast@philabs.UUCP Thu Nov  3 09:15:40 1983
Date: Thu, 3 Nov 83 13:43:45 -0100
From: mcvax!vu44!ast
Subject: compiler kit
Message-Id: <8311031243.AA02274@mcvax.UUCP>
Received: by mcvax.UUCP (4.12/3.14)
	id AA02274; Thu, 3 Nov 83 13:43:45 -0100
Received: by cbosgd.UUCP (3.327/3.7)
	id AA17012; 3 Nov 83 09:15:32 EST (Thu)
Sent-By: philabs.UUCP Thu Nov  3 09:12:20 1983
Apparently-To: philabs!cbosgd!mark
Status: R

It is true our stuff is not public domain, but we may be easier to deal with
than Western.

As an aside, I have also rewritten UNIX from scratch.  It is not quite finished
although it is pretty close.  What I am going to do with it is not clear yet.




Date: Thu 3 Nov 83 18:21:43-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Parser generators
To: info-gnu@MIT-MC

To be most useful, a Yacc replacement should accept the
exact same input that real Yacc does, and produce the exact same 
format output (so that people who are used to using Yacc output
can make use of the output of its replacement with no change).
Versions that used other formats of input and output might also
be useful in certain situations, but the truly compatible one
is the most important.

How hard would it be to make LLAMA use the same input and output formats
that Yacc uses?

What about the Lisp program you are writing?
-------

Received: from ucbernie.ARPA by ucbvax.ARPA (4.16/4.13)
	id AA01272; Wed, 2 Nov 83 16:44:18 pst
Received: by ucbernie.ARPA (4.17/4.13)
	id AA22791; Wed, 2 Nov 83 14:23:18 pst
Date: Wed, 2 Nov 83 14:23:18 pst
From: phr%ucbernie@Berkeley (Paul Rubin)
Message-Id: <8311022223.AA22791@ucbernie.ARPA>
To: info-gnu@mit-mc
Subject: parser generators

I have a copy of a PD parser generator similar to Yacc.  It was written
in Pascal by Tim Murphy, Brian Dunn, and Ken Robinson at the University
of New South Wales, reads Pascal semantic actions and produces a Pascal
translator.  It's called LLAMA, which seems like a perfect name for a
GNU program, and it's complete and documented, about 3000 lines of
Pascal.  The man page says "This version is intended more for teaching
than for production use" and describes a few problems, but I think that
most of its idiosyncrasies could be removed pretty easily (even the
Pascal output).

Also I'm sporadically working on a Lisp version that will use some new
algorithms more efficient than Unix Yacc (I don't yet know what LLAMA
uses).  This is for a school project so I actually intend to get somewhere
with it (I keep telling myself).  More about this as it progresses.


Date: Thu 3 Nov 83 02:29:14-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: VU compiler kit, old versions
To: info-gnu@MIT-MC

Some people reported seeing old versions of compilers
coming from Amsterdam, and thought they were free.
Can anyone who has seen them look for them and verify
what indeed they saw, whether it is free, etc?
If it is free, it may be useful.
-------

Received: by ucbvax.ARPA (4.16/4.13)
	id AA05535; Wed, 2 Nov 83 21:43:05 pst
Date: 2 Nov 83 20:10:00 EST (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: VU Compiler Kit Info
Message-Id: <8311030110.AA13017@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA13017; 2 Nov 83 20:10:00 EST (Wed)
To: info-gnu@mit-mc.ARPA

I received this today.  It appears that even if you rewrote the C front
end, you'd find that the VU stuff is a commercial product rather than
public domain.  However, you never know what negotiations might produce.

>From mcvax!vu44!ast@philabs.UUCP Wed Nov  2 17:39:31 1983
Date: Tue, 1 Nov 83 09:57:33 -0100
From: mcvax!vu44!ast
Message-Id: <8311010857.AA04838@mcvax.UUCP>
Received: by mcvax.UUCP (4.12/3.14)
	id AA04838; Tue, 1 Nov 83 09:57:33 -0100
Received: by cbosgd.UUCP (3.327/3.7)
	id AA12072; 2 Nov 83 17:39:26 EST (Wed)
Sent-By: philabs.UUCP Wed Nov  2 01:44:52 1983
Apparently-To: philabs!cbosgd!mark
Status: R

Dear Mr. Horton,
   Somewhat indirectly I saw a piece of news that you apparently put on the
net that asks some questions that I can probably answer concerning the
Amsterdam Compiler Kit.

   The current status is as follows:

     Front ends:
        Pascal: finished
        C: finished
        Plain: in progress (in collaboration with Prof. A. I. Wasserman, UCSF)
        Algol 68: in progress (being done by Prof. C. Lindsey, Manchester)
        Ada: under discussion

     Peephole optimizer: finished

     Back end: Program is finished
         DEC PDP-11 table: finished
         DEC VAX table: finished
         Intel 8086/8088 table: finished
         Motorola 68000 table: finished
         Motorola 6809 table: in progress
         Zilog Z80 table: in progress
         Zilog Z8000 table: in progress
         Mostek 6502 table: in progress
	 Intel 8080 table: in progress
         National Semiconductor 16032 table: to be started shortly

     Universal Assembler/Linker: Program is finished
        Intel 8080 table: finished
        Intel 8086/8088 table: finished
        Motorola 6800 table: finished
        Motorola 6809 table: finished
        Motorola 68000 table: finished
        Zilog Z80 table: finished
        Zilog Z8000 table: finished
        National Semiconductor 16032 table: to be started shortly

     EM Interpreters:
        DEC PDP-11: finished
        Zilog Z80: finished
        Motorola 68000: in progress

     Miscellaneous:
        EM assembler (translates EM to binary for interpretation): finished
        EM, Pascal, and C test programs: finished
        Various libraries and utility programs are also provided

Licensing
     The Compiler Kit is  only  available  to  organizations  holding a SOURCE
license  from  Western Electric for the UNIX* Timesharing System.  For licensing
reasons it cannot be provided to organizations holding BINARY license
at this time.  Three categories of licenses exist for the compiler kit:

   Universities - source available for $500 for research/education only
   Single CPU commercial licenses  - price not yet set
   OEM licenses -  price not yet set + 30% royalty (probably)

None of these licenses provide support.   We are currently  negotiating  with
potential dealers who will then resell the Compiler Kit with support.
Binary licenses may also be  available  through  dealers  eventually.

     The compiler kit itself is written in C/Yacc, except for the Pascal
front end, which is written in Pascal.  The whole thing runs on the following
machines and systems:

   PDP-11/44 with V7 UNIX
   VAX with Berkeley 4.1
   68000 with System III

     With the exception of the C front end, everything is our property and
no subject to Western's license.  The C front end is based on pcc, and as
such is subject to Western's conditions.  If you know someone who is willing
to produce a C to EM (our intermediate code) front end, then that would
solve a lot of problems. 

     If you have more questions, you can get to me at

   ...decvax!mcvax!vu44!ast

					Andy Tanenbaum



[He can be reached from the ARPANET as decvax!mcvax!vu44!ast@Berkeley.ARPA]

Date: 2 Nov 83 19:11:00 PST (Wed)
From: Howard Alt <alt@aids-unix>
Subject: Re:  Terminal control
Message-Id: <8311030311.AA08749@aids-unix.ARPA>
Received: by aids-unix.ARPA (3.326/3.14)
To: RMS@MIT-OZ, @, MIT-MC@aids-unix, info-gnu@MIT-MC

An interesting idea.  There was a version of Unix called Unix RT.  It
was a version of unix written for real time control (I think).  Anyway,
they made the device drivers seperate processes.  I think this is a 
really neat idea since it makes things like autoconfigure, adding
a new device, etc really easy.  Also, you don't have to recompile
the kernel each time you change somthing (keeps you away from
having to adb /vmunix /dev/kmem).

Anyway, this is probably a neat idea, and it would (I think) help
the screen oriented terminal independent tty driver (getting
at the filesystem from inside the kernel is not really very
easy... at least I've never tried it... I'm thinking of the
terminal description database... you don't really want to
keep that inside the kernel).  

Any other thoughts on the subject?
				Howard.

Date: Wed 2 Nov 83 15:49:58-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Terminal control
To: info-gnu@MIT-MC

I think it is important to take terminal control out of the individual
user program and put it in some place that remains for the whole session.
Also, the interfacing should be done in a way such that the same user
program should work for both systems with conventional terminals
and systems with bit-map screens and window systems.  It should not
even require recompilation, since often the same CPU type will be used.
Perhaps it is possible to use the code or the interface of curses
in doing this; they aren't what I meant by "the curses way of doing things".
-------

Received: by ucbvax.ARPA (4.16/4.13)
	id AA12944; Tue, 1 Nov 83 19:17:21 pst
Date: 1 Nov 83 13:45:28 EST (Tue)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re:  The fastest way to write programs ...
Message-Id: <8311011845.AA02033@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA02033; 1 Nov 83 13:45:28 EST (Tue)
To: info-gnu@mit-mc.ARPA

	Debuggers:
		Are any of the Berkeley debuggers public domain?  Are there any
	UNIX debuggers that are public domain?  Most of the UNIX debuggers do
	the job, but don't really seem very special.
4.2BSD has dbx, which appears to have been done at Berkeley.

	Shell:
		The C-shell does not seem to be based on any Bell software, and
	I think that all the Berkeley software is public domain (an ARPA
	grant), but I am not sure.  In any case, the shells could probably be
	improved.  Bill Joy wrote the C-shell, so he would be the best one to
	ask if it is public domain.  I asked an old cohort of his, who thought
	that it was not under any copywrite, but wasn't sure.
Sorry, but csh is NOT PD.  It has the V6 sh inside it.

	terminal-independent display support:  The other has been done by Pavel
	Curtis at Cornell, and is public domain.  An old, buggy version of
	Pavel's ncurses is being distributed with 4.1c.  We use a newer version
	at Cornell, but there are still a couple of bugs left for Pavel to fix,
	and it needs to be a lot faster. However, I always use it in preference
	to curses.
I don't know if you got it, but there is a 1 line fix to Pavel's curses that
speeds it up an amazing amount.  It involves not updating a line if there
have been no changes to it since the last refresh.

	mailer:
		Any good ideas?
sendmail and Mail are both PD.  /bin/mail is not, but who cares?

	more, finger, ctags, etc.:
		There are a great many small programs that have been written at
	Berkeley.  Does anybody know whether these are public domain or not?
These 3 programs, and anything else done at UCB and on the tape, is PD.

	Mark

Date: 1 November 1983 20:31 EDT
From: Andrew Scott Beals <BANDY @ MIT-ML>
Subject:  Fen's phone number is really (408) 298-6850
To: RMS @ MIT-OZ
cc: info-gnu @ MIT-MC
In-reply-to: Msg of Tue 1 Nov 83 16:10:28-EST from RMS%MIT-OZ at MIT-MC.ARPA

... the number you gave is for the other building ...

	Andy


Date: Tue 1 Nov 83 16:10:28-EST
From: RMS%MIT-OZ@MIT-MC.ARPA
To: info-gnu@MIT-MC

I'm happy to use any existing free programs that do their jobs well.
Not being a Unix wizard, I did not have any idea what was available.
I'm happy to see a survey.

There will be no shortage of editors.  Both jpayne@bbn-unix and
klh@sri-kl have written free ersatz EMACSes either of which we could use.
Also, Gosling's is in fact available.  Fen Labalme of Megatest has done
a lot of work on it and he and Megatest claim they are allowed to
distribute it.  And they are doing so, free.  They are openly defying
Unipress.  If you are using Gosling's or know anyone who is, get Fen's
improved and free version right away and start propagating it.
Call him at (408) 988-1700.

I do not think that curses is a good way to do display control.
While it does eliminate the need to write display handling for each
program, the fact that it resides separately in each program that
uses it means it is suitable only for individual programs that use
the entire screen regardless of what any other program has output
(for example, screen editors).  It is also useful to have the
primary output channel, the thing that the shell and everything
else normally sends output to, be capable of display handing,
and since this is shared by many programs, it cannot be managed by
a curses living in each one.  The handler for it must be outside
the user's programs, either in the kernel or in a separate display
handler fork.  Nor is the curses approach any good for a window
system the allows different programs to use different parts of the screen.
-------

From: rej@Cornell (Ralph Johnson)
Date: 31 Oct 83 16:26:06 EST (Mon)
Subject: The fastest way to write programs ...
Message-Id: <8310312126.AA10811@GVAX.CORNELL>
Received: by GVAX.CORNELL (3.320/3.14)
	id AA10811; 31 Oct 83 16:26:06 EST (Mon)
To: info-gnu@mit-mc

The fastest way to develop a good software system is to borrow
programs, not to write them.  I think that the majority of UNIX-like
tools that are needed for GNU already exist.  The following comments
are written with the awareness that much non-Bell UNIX software uses
parts of earlier Bell software, so it cannot be borrowed without
risk of lawsuit (and such borrowings would be immoral, as well).
I am trying to mention only those programs which are public domain
and are good enough to borrow.  The organization of this message will
consist of an annotated list of all programs that will be needed for
GNU.  This organization should make it easy for other people to fill
or change in the vast amount of information that I will ingnore or
get wrong.

the kernel:
	There seems to be no way around writing this.  Many
groups have written their own versions of the UNIX kernel, but
none of the ones that I have heard about are public domain or
have the features suggested by Richard Stallman.  One system that
I have heard about is Tunis, from U. of Toronto (written in Concurrent
Euclid, I believe).  Tunis was written to provide a UNIX that could
be studied in an operating systems class.  Holt has written a book
called Tunis, UNIX, and ??? which was recently published.  I have
not seen the book but it should talk about UNIX internals.  Tunis
is supposed to have a much cleaner and "modern" internal organization
than UNIX, so it might be useful to look at how some modern O.S.
builders would design UNIX.
	Many of the features that were going to be added to GNU are
part of BSD 4.2, so it would be smart to use the 4.2 interface
definitions.  My understanding is that future Bell standards will
incorporate the 4.2 design.

C compiler, linker, assembler:
	If the Amsterdam Compiler Kit (also called the Free University
Compiler Kit by some in this group) turns out to be good, these
problems are solved.

Debuggers:
	Are any of the Berkeley debuggers public domain?  Are there
any UNIX debuggers that are public domain?  Most of the UNIX debuggers
do the job, but don't really seem very special.

LISP:
	I have used Franz Lisp a bit and it seemed fine, but then I am
not a LISP hacker.  I have heard a good deal of complaining about it
from people who seemed pretty biased.  It is public domain and there is
a 68000 implementation.  In addition, I have seen a number of announcements
from various groups indicating that they had a super-duper LISP to give
away.  As I indicated, I am not up on LISP doings.  What are your plans,
Richard?

Editor:
	I really like Gosling's editor.  Too bad it is a commercial
product.  However, I am sure you can do as good a job.

Shell:
	The C-shell does not seem to be based on any Bell software, and
I think that all the Berkeley software is public domain (an ARPA grant),
but I am not sure.  In any case, the shells could probably be improved.
Bill Joy wrote the C-shell, so he would be the best one to ask if it is
public domain.  I asked an old cohort of his, who thought that it was
not under any copywrite, but wasn't sure.

Source Code Control:
	RCS is much better than SCCS and is public domain.

Text formatter:
	I like TeX.  It is much easier to learn and to use than
{t|n}roff and produces prettier output.  It is also public domain
and portable (in Pascal).  However, it requires dot addressable
output devices, so it won't work on standard crts.  Perhaps TeX
could be modified to produce a version that is to standard TeX as
nroff is to troff.  In any case, rewriting troff or nroff would
be a gigantic headache.  If nroff is not rewritten, however, all
manual pages will have to be converted to the new formatter.  I
have a sed script which converted my thesis from troff to TeX.
Perhaps the same thing could be done for manual pages.

YACC:
	YACC has become a standard UNIX programming language.  Although
the state of the art in compiler-compilers has improved since the time
that YACC was written, it will still be necessary to provide something
that is YACC compatible.  For example ...

Spreadsheets:
	I have fooled around with Gosling's sc spreadsheet.  I was
impressed by all the power in a tiny package.  While a number of
things need to be added before sc rivals 1-2-3, it is easy to add
and change features.  As I hinted, sc relies on YACC a great deal.

Database:
	Berkeley's Ingres is public domain and quite portable.  It is
not all that efficient, but it seems to do all you would want a one
machine relational database system to do, except there is no report
generator or screen definition language.  These should not be hard to
add.

terminal-independent display support:
	The standard UNIX package is the curses subroutine package with
the termcap data-base.  The second generation (up-ward compatible) is
ncurses with the terminfo data-base.  There are two versions of ncurses.
One has been done by Mark Horton at Bell Labs, and is propriatary.  The
other has been done by Pavel Curtis at Cornell, and is public domain.
An old, buggy version of Pavel's ncurses is being distributed with 4.1c.
We use a newer version at Cornell, but there are still a couple of bugs
left for Pavel to fix, and it needs to be a lot faster. However, I
always use it in preference to curses.

mailer:
	Any good ideas?

more, finger, ctags, etc.:
	There are a great many small programs that have been written at
Berkeley.  Does anybody know whether these are public domain or not?

sed, awk, diff, mv, rm, cp, ls, pr, cat, etc.:
	This list contains all the small programs that are gen-u-ine
UNIX.  I don't know much about the Software Tools.  Are these there?



	Please feel free to add to this list.  When I asked Richard
how much he was planning to write from scratch, he said "all of it".
Since there is a lot of UNIX software from universities and the like,
it would seem best to borrow as much as possible, leaving Richard
the fun job of writing the kernel.  Comments?


	Ralph Johnson  (rej@cornell, cornell!rej)

Received: by ucbvax.ARPA (4.16/4.13)
	id AA12753; Thu, 27 Oct 83 14:46:36 pdt
Date: 27 Oct 83 16:15:01 EDT (Thu)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: fortran to c translator
Message-Id: <8310272015.AA04282@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA04282; 27 Oct 83 16:15:01 EDT (Thu)
To: info-gnu%mit-oz@mit-mc.ARPA

Consider this a 3rd class lead, but when I was at Wisconsin in 1977,
a grad student there wrote a fortran-to-c translator (this was Fortran
66 and V6 C) as a class project.  I probably have a copy of it on a
magtape somewhere (in tp format, no doubt).  It didn't work all that
well, but if someone is into hacking on it it's a starting point.

	Mark

Mail-From: RMS created at 13-Oct-83 06:51:55
Date: Thu 13 Oct 83 06:51:55-EDT
From: RMS@MIT-OZ
Subject: STUG phone and address
To: rms@MIT-OZ
ReSent-date: Thu 27 Oct 83 12:50:29-EDT
ReSent-from: RMS%MIT-OZ@MIT-MC.ARPA
ReSent-to: info-gnu@MIT-MC

tab@lbl-csam for ratfor-c
deerinck@lbl-csam for STUG in general.

(415) 486-6411

Software Tools Users Group
242 El Camino Reak #1259
Menlo Park, CA 94025
-------

Date: Thu 27 Oct 83 12:49:57-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Found info on Free University Compiler Kit
To: info-gnu@MIT-MC

(I think it's really Vrije Universiteit.  I'm not completely certain
that Vrije means Free.)  It is a compiler that handles any vaguely
Algol-like language (including Fortran, Pascal, or probably C)
if you write a front end, and can generate code for anything that
addresses 8-bit bytes.  The article describing it is in the September
Comm ACM.  It does not say how the program is available, just to
ask the authors.  I am doing that now.
-------

Date: Wed 26 Oct 83 13:59:12-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Free University Compiler Kit - need info
To: info-gnu@MIT-MC

Can anyone tell me, from direct knowledge,
what the Free University Compiler Kit exactly consists of
(which languages are supported by it, and which CPUs already handled),
or what exactly the terms are that it is available on,
or the name and address to obtain it from,
or the name and address of someone who knows?
-------

Received: from ucbernie.ARPA by ucbvax.ARPA (4.16/4.11)
	id AA02594; Tue, 25 Oct 83 19:01:09 pdt
Received: by ucbernie.ARPA (4.16/4.8)
	id AA06945; Tue, 25 Oct 83 19:09:42 pdt
Date: Tue, 25 Oct 83 19:09:42 pdt
From: phr%ucbernie@Berkeley (Paul Rubin)
Message-Id: <8310260209.AA06945@ucbernie.ARPA>
To: rminnich%udel-eecis1.udeecis@udel-ee.ARPA
Subject: Re:  trix, license, ratfor
Cc: info-gnu@mit-mc

There were a few problems with doing Fortran the way you suggest.  I
don't remember all the difficulties but some are:
	equivalence, common (Software Tools are full of these)
		(can be done with ptrs, but it means that the translator
		has to almost be a compiler)
	complex arithmetic
	multi-dimensional arrays as parameters (have to pass dimensions
		or dope vectors or something)
	statement functions (ST has a few of these which can be hand-fixed)
	Fortrash I/O (can be ignored for our purposes, I think but a real
		Fortran should include formatted i/o, namelist, define file
		statements and all that rot)
	labels as parameters (call foo (x, y, &99) where 99 is a label)
	scalar parameters are supposed to be call by value-result, not
		call by reference.
	etc. etc. etc.

I think that the more reasonable approach of a Fortran front end for
whatever we wind up using for a C compiler wouldn't be harder than
translating Fortran to C.  GNU should eventually have a good Fortran,
sick as it seems, for scientific computation.  DEC Fortran is for many
VAX VMS sites the sole reason for not running Unix.

	paul rubin

PS. Is anyone out there willing to field-test a yacc clone written in Lisp?
(It won't be ready for a while yet).

BTW, what is TRIX?

Date:     Sun, 23 Oct 83 17:39:03 EDT
From:     Ron Minnich <rminnich%udel-eecis1.udeecis@udel-ee.arpa>
To:       info-gnu%mit-oz@mit-mc.arpa
Subject:  trix, license, ratfor

TRIX: Is there any way I can get ahold of TRIX without a license? Not
the compiler, just the code for the OS, or any parts one can get
without the license.  If so, I could try to bring it up on some of 
the machines I have access to-11/23, IBM PC, FORTUNE, and others.
I do not know if that would be any help, but if it would, I would
gladly try to do it.
LICENSE: I am sure that ATT can buy better justice than we. To avoid 
even the possibility of problems, I bought my own machine instead of 
using university machines. I do not know all the ins and outs of the 
contract, but I do know that things are a lot more restrictive than they
were in 1976, when we used to hand out source in classrooms and teach a
course from it. Some people have told me that that is verboten nowadays.
FORTRAN- I looked at this. One could write a pretty good Ratfor-to-C
by making all parameters be reference parameters (lots of & and * ...).
The software tools people use white space well enough to make this
approach easy to do.
That is the quickest, cheapest,
and ugliest. After trying this route with Software Tools ed I found it 
easier to rewrite from scratch, borrowing the basic structure.
ron

Date: Tue 18 Oct 83 08:50:57-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: Please volunteer to write a parser for Fortran.
To: info-gnu@MIT-MC.ARPA

In order to use the Software Tools, I will need to be able to run Ratfor.
Since there is already a free Ratfor to Fortran translator, it seems
most useful to have a Fortran compiler.  I could make this most easily
by using most of a C compiler plus a parser for Fortran.  Would someone
please volunteer to write the parser?

The parser would read the Fortran text and produce in core a
tree-structure representation of the code.  Design the tree structure
whichever way you like; it can always be adapted to fit the compiler
later.

If it is easiest to do this using YACC, that's fine, since a free YACC
and LEX are coming from Software Tools.  Use the Unix YACC for now.
Though I tend to doubt it can deal with Fortran's weird syntax.

I can probably get ahold of a Fortran to Lisp translator written in Lisp
which you could read to answer any obscure questions about how to parse
Fortran properly.  There are lots of near-ambiguities which are not
too hard to deal with if you know the right trick to use.

Alternatively, you could write a Ratfor to C translator.  This could get
the job done even if there were a few situations it could not deal with,
as long as it would print an error message to tell the user to fix them
up by hand.  With this, someone would have to translate the tools to C
once, and we would then distribute and use them in C.
-------

Date:     16 Oct 83 18:13:37 EDT  (Sun)
From: Mark Weiser <mark%umcp-cs@CSNet-Relay>
Return-Path: <mark%umcp-cs@CSNet-Relay>
Subject:  Re:  I don't believe it is so.
To: RMS%MIT-OZ@mit-mc, info-gnu%MIT-OZ@mit-mc
Via:  UMCP-CS; 16 Oct 83 18:16-EDT

My understanding, in spite of being the one who started this round
of rumors, is that RMS and others are right, using Unix to develop
software doesn't give Bell any rights unless the software only
runs under Unix.  In that case, they feel that you can only give
the source code to places that have Bell sources licenses, etc.
If the program doesn't require any Unix utilities to run then they
admit they have no control.

Of course, no matter what, Bell doesn't own the product.  It's just
that sometimes they think they have some say over who can see it.

Date: Sun 16 Oct 83 05:05:15-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: I don't believe it is so.
To: info-gnu%MIT-OZ@MIT-MC.ARPA

I do not think it is the case that Unix license restrictions
have any effect on programs that people write themselves
using Unix.  Just consider how many software houses there are
that use Unix for their work and do not agree that their
products belong to Bell.  I am going to be using Unix
for development myself, until I have developed enough to
throw the Unix away.

So far all rumors of any such problems have proved groundless
when I have investigated them.  I don't think it's worth
investigating any unless they come with solid evidence.
-------

Date: Sun 16 Oct 83 05:05:15-EDT
From: RMS%MIT-OZ@MIT-MC.ARPA
Subject: I don't believe it is so.
To: info-gnu%MIT-OZ@MIT-MC.ARPA

I do not think it is the case that Unix license restrictions
have any effect on programs that people write themselves
using Unix.  Just consider how many software houses there are
that use Unix for their work and do not agree that their
products belong to Bell.  I am going to be using Unix
for development myself, until I have developed enough to
throw the Unix away.

So far all rumors of any such problems have proved groundless
when I have investigated them.  I don't think it's worth
investigating any unless they come with solid evidence.
-------

Received: from ucbkim.ARPA by ucbvax.ARPA (4.12/4.7)
	id AA14044; Fri, 14 Oct 83 06:54:18 PDT
Received: by ucbkim.ARPA (4.6/4.2)
	id AA12738; Fri, 14 Oct 83 06:55:21 PDT
Date: Fri, 14 Oct 83 06:55:21 PDT
From: bh%ucbkim@Berkeley (Brian Harvey)
Message-Id: <8310141355.AA12738@ucbkim.ARPA>
To: mark%umcp-cs@CSNet-Relay
Subject: Re:  Jay Fenlason
Cc: info-gnu@mc, jf%ernie@Berkeley

Why is that true?  Berkeley has a commercial Unix license, so that can't
be the problem, and Jay does not have access to Unix sources through
Berkeley, so that can't be it either.  And in any case the software he
is offering to contribute is not a reimplementation of anything Bell offers.

Date: 14 Oct 1983 01:31:00-EDT
From: gill at mitccc
To: info-gnu@mit-oz

There are three names in the info-gnu@mc mailing list that get
rejected by comsat. Will someone fix this?

	Gill

Date: 14 Oct 1983 01:31:00-EDT
From: gill at mitccc
To: info-gnu@mit-oz

There are three names in the info-gnu@mc mailing list that get
rejected by comsat. Will someone fix this?

	Gill

Date: 14 Oct 1983 01:28:22-EDT
From: gill at mitccc
To: info-gnu@mit-oz
Subject: Forwarded-mail

>From COMSAT@MIT-MC Fri Oct 14 01:26:30 1983
Date: 14 October 1983 01:26 EDT
From: Communications Satellite <COMSAT @ MIT-MC>
Subject: Msg of Friday, 14 October 1983 01:26 EDT
To: gill @ MIT-CCC

============ A copy of your message is being returned, because: ============
"MIT-VAX" at MIT-MC is an unknown recipient.
    This name came from the expansion of
    INFO-GNU
"AT" at MIT-MC is an unknown recipient.
    This name came from the expansion of
    INFO-GNU
	Will try sending to the file "GUEST0;AT MAIL".
"EAGLE!MHUXI!IHNP4!CLYDE!AKGUA!SB1!LL1!OTUXA!NWUXD!JAB" at MIT-MC is an unknown recipient.
    This name came from the expansion of
    INFO-GNU
============ Failed message follows: ============
Date: 14 Oct 1983 01:26:06-EDT
From: gill at mitccc
To: mark@umcp-cs@udel-relay
Subject: Development of GNU ;; can we use UNIX systems?
Cc: info-gnu@mit-mc

It is not at all clear whether AT&T can dictate toward what
end work may be done on UNIX machines. On machines given licenses for
educational purposes, they can, but several schools have already licensed
commercial products originally developed on "educational" UNIX systems
(albeit usually at a nominal cost). 

Although it may seem cruel to use BTL's past generosity towards schools
(a.k.a. free UNIX source licenses) to such ends (i.e. undermining
the UNIX market), I don't believe there is anything they can do about
it. Writing a new operating system is certainly an educational activity,
and if the result is not used for profit (which is the spirit of GNU),
I see little BTL can do to stop students from giving away the results
of their educational experience.

This is not to say that I haven't been advised to have the MIT GNU effort
make as clean a break from BTL as possible. I haven't decided how far
we will have to go; using UNIX to bootstrap the system would be handy.
Luckily, there exists a new operating system developed by Jon Seber et.
al. at the Real Time Systems Lab called "TRIX" that I predict will be
used instead. TRIX is compatible with UNIX in sufficient ways that
it makes as good a development system as UNIX. In fact, I am considering
TRIX's innovative structure as a model for GNU's kernal. The C compiler,
howerever, is derived from PCC.

No matter what system people choose to develop their software on, be
forwarned; the amount of AT&T owned software currently licensed under
UNIX is not to be sneezed at; the urge to borrow is strong, and will
grow as people come to realize the enormity of the task (I believe
that the community willing to work on GNU is up to it). If one thing
can turn GNU from early success to abysmal failure, it is a law suit 
against a school or individual from AT&T. So please, whatever you write,
be VERY careful about your code's pedigree. 

	Gill Pratt



Date: 14 Oct 1983 01:26:06-EDT
From: gill at mitccc
To: mark@umcp-cs@udel-relay
Subject: Development of GNU ;; can we use UNIX systems?
Cc: info-gnu@mit-mc

It is not at all clear whether AT&T can dictate toward what
end work may be done on UNIX machines. On machines given licenses for
educational purposes, they can, but several schools have already licensed
commercial products originally developed on "educational" UNIX systems
(albeit usually at a nominal cost). 

Although it may seem cruel to use BTL's past generosity towards schools
(a.k.a. free UNIX source licenses) to such ends (i.e. undermining
the UNIX market), I don't believe there is anything they can do about
it. Writing a new operating system is certainly an educational activity,
and if the result is not used for profit (which is the spirit of GNU),
I see little BTL can do to stop students from giving away the results
of their educational experience.

This is not to say that I haven't been advised to have the MIT GNU effort
make as clean a break from BTL as possible. I haven't decided how far
we will have to go; using UNIX to bootstrap the system would be handy.
Luckily, there exists a new operating system developed by Jon Seber et.
al. at the Real Time Systems Lab called "TRIX" that I predict will be
used instead. TRIX is compatible with UNIX in sufficient ways that
it makes as good a development system as UNIX. In fact, I am considering
TRIX's innovative structure as a model for GNU's kernal. The C compiler,
howerever, is derived from PCC.

No matter what system people choose to develop their software on, be
forwarned; the amount of AT&T owned software currently licensed under
UNIX is not to be sneezed at; the urge to borrow is strong, and will
grow as people come to realize the enormity of the task (I believe
that the community willing to work on GNU is up to it). If one thing
can turn GNU from early success to abysmal failure, it is a law suit 
against a school or individual from AT&T. So please, whatever you write,
be VERY careful about your code's pedigree. 

	Gill Pratt

Date:     12 Oct 83 23:36:30 EDT  (Wed)
From: Mark Weiser <mark%umcp-cs@CSNet-Relay>
Return-Path: <mark%umcp-cs@CSNet-Relay>
Subject:  Jay Fenlason
To: (Jay Fenlason) jf%UCBERNIE@Berkeley, info-gnu@mc
Via:  UMCP-CS; 12 Oct 83 23:45-EDT

Unfortunately, Jay, to avoid Unix license restrictions you
must work on your gnu contributions from a non-Unix machine,
and there are not any such at Berkeley.  You should have
gone to Kalamazoo Barber College: all their machines are
non-Unix. ;-)

Received: by ucbvax.ARPA (4.12/4.7)
	id AA24086; Mon, 10 Oct 83 20:46:02 PDT
Date: 3 Oct 1983 22:29-PDT
From: John Gilmore <sun!gnu@Berkeley>
Subject: Uh, I'm flattered, but...
Message-Id: <8310101819.AA03913@sun.uucp>
Received: by sun.uucp (3.320/3.14)
	id AA03913; 10 Oct 83 11:19:30 PDT (Mon)
To: @MIT-MC.arpa:RMS@MIT-OZ.arpa
ReSent-date: Thu 13 Oct 83 07:15:11-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

...am also curious where the name "GNU" came from.  (I used to be GNU@AI
and am now occasionally GNU@OZ.  Mostly now I'm sun!gnu@Berkeley.)
Actually it might be fun to have my pseudonym adopted by a free public
domain Unix replacement.  Once I am not totally occupied with working
at Sun, I can probably even contribute code and time.

I presume you're writing in C.  The first step, then, will be a public
domain portable C compiler.  That in itself would be a worthwhile
contribution to the public welfare.  There don't seem to be any good
(free) bases to start from; what are your plans?


Received: from CU20B by CUCS20 with DECnet; 12 Oct 83 14:55:25 EDT
Date: Wed, 12 Oct 1983  14:47 EDT
From: David Millman <CU.DSM@CU20B>
To:   RMS@MIT-OZ
CC:   phr%UCBERNIE@Berkeley (Paul Rubin)
Subject: GNUWS
ReSent-date: Thu 13 Oct 83 07:15:00-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

hi.

Please add me (CC.DSM@Columbia-20, NOT the address above, which
will probably not be recognized as a known host) to the GNU
mailing list.  Also: can I get copies of the stuff send out so
far?

thanks

d


Date: 11 Oct 1983 20:33:11-EDT
From: allegra!jac at mit-vax
To: mit-vax!RMS@mit-oz
ReSent-date: Thu 13 Oct 83 07:14:19-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

subject:gnu


	Sounds like a great idea to me !!!

	Why not make it portable.  I would love to run UNIX (tm)
on a small machine (read homebuilt).  

	Please send me any information you have, and add me to
your mailing list.

	Thanks,

			Jonathan A. Chandross
			Allegra!jac


Date:  7 Oct 1983 0304-PDT
From: MUEHLEN at SRI-CSL
Subject: Free Unix
To: rms at MIT-MC
cc: muehlen at SRI-CSL
ReSent-date: Thu 13 Oct 83 07:13:09-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

I would like to contribute to GNU by writing a compatible duplicate.
We are new in UNIX applications. We would like to start with an
window system (window manager). Which Window system we should start with?
we are 1 researcher and two students. Thanks
Heinz Muehlenbein (germany)
-------

Date: 6 Oct 1983 12:55:44-PDT
From: diamant.Case@Rand-Relay
Return-Path: <diamant.Case-Western@Rand-Relay>
Subject: resend of message about GNU
To: rms@oz, @, mit-mc.Case@Rand-Relay
Via:  Case-Western; 6 Oct 83 22:19-PDT
ReSent-date: Thu 13 Oct 83 07:12:56-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

My appologies if you already got this, but I got a failure message when
I sent it, and I am trying with a different path.  Here is the message:

Yes, please send me the long version of the announcement, and add me to
the INFO-GNU mailing list.  By the way, what machine is this system
geared to? (If that is answered in the announcement, you needn't answer
this individually).

					John Diamant
				Usenet: ...decvax!cwruecmp!diamant
				CSNet:  diamant@Case
				ARPA:   diamant.Case@Udel-Relay



Date: 8 Oct 1983 23:07:26-PDT
From: utcsrgv!peterr@uw-beaver
To: uw-beaver^RMS@MIT-MC
Subject: GNU
Cc: peterr
ReSent-date: Thu 13 Oct 83 07:11:34-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

I applaud the spirit behind your project and wish I had the time and
resources to work on it.  I'm a grad student, trying to sell
software on the side; should I ever make enough to get a reasonable system
together, I'd be happy to contribute to your project.  I'm afraid that
won't happen in the near future, though.
  Others may have said this, but in case they haven't:  A lot has been
learned about operating systems since UNIX was born and it'd be nice to
take advantage of that.  A system developed here, called TUNIS (and
documented in a recent Addison-Wesley book by R.C.Holt) applied Hoare
monitor and Pascal-like language technology to the production of a UNIX
"plug-compatible" operating system.  As a project, it's been stalled the
last little while, but I believe it is now being commercialized.  Sadly,
in Canada university-developed software is not automatically in the public
domain, otherwise this would be a great place to start.  The same goes for
Thoth and its successor Port, developed at the University of Waterloo,
that took a message passing view.  QNX (formerly QUNIX), which is a UNIX
lookalike for the IBM PC, is heavily based on Thoth.
  Apart from using new programming technology to build a UNIX with a few
extensions, I think it'd be nice to consider some major extensions, like
dynamically-loaded routines via segments a la Multics.  Much more work
there, though, and I guess the current hardware might not be up to it;
on the other hand, current hardware isn't up to Smalltalk, but it seems
to have enough of a future to INFLUENCE future hardware, which a GNU might
also do.
  In summary, it'd be great to have a public-domain stock AT&T UNIX, but
if you're so inclined, you have a great opportunity to make substantial
improvements, both internal (possibly reducing your development time)
and external.
  Ric Holt, architect of TUNIS (and my MSc supervisor) is reputed to be
an ex-hippy, and I know for sure he served in the US Peace Corps, but I
can't quite figure out his philosophy now.  He might be sympathetic.
His userid is utcsrgv!rch.
  As for the sociology of the project and people screaming at you that
competition for money is the only way to produce quality software, I
strongly disagree with them; all the quality-circle and related matters
show that there's a lot more to producing quality goods than paying people--
believing in a project is more important.

peter rowley,  University of Toronto Department of C.S., Ontario Canada M5S 1A4
UUCP: {cornell,watmath,ihnp4,floyd,allegra,ubc-vision,uw-beaver}!utcsrgv!peterr
      {cwruecmp,duke,linus,decvax,research}!utzoo!utcsrgv!peterr
ARPA: utcsrgv!peterr@UW-BEAVER


Date: 5 Oct 1983 19:08:05-EDT
From: eagle!mhuxi!ihnp4!clyde!akgua!sb1!ll1!otuxa!nwuxd!jab at mit-vax
ReSent-date: Thu 13 Oct 83 07:09:11-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA


I cheer you on. Good luck.

Unfortunately, I'm not presently in a position to offer my services; I have
signed such an agreement (nasty thing, really) and therefore can't really
help you on PROGRAMS THAT APPEAR ON THE UNIX TAPES THAT BELL DISTRIBUTES.
However, if you have *other* things (text formatter, for example) or
something of that sort, I'll be glad to donate what time that I have.

Please call me at (312) 260-4880 when you get a chance. 

Again, good luck.

	Jeff Bowles

ps. Also, ctvax!uok!andree (Mike Meyer, at the University of Oklahoma) 
will be interested in this; he's the one who told me about your endeavors.
I'll pass your address on to him. What's your USnail address, again?










Date: Thu 13 Oct 83 07:05:26-EDT
From: RMS%MIT-OZ@MIT-ML.ARPA
To: info-gnu%MIT-OZ@MIT-ML.ARPA

I contacted STUG and someone there is going to mail me a list of
exactly what they have available.  They know of someone writing
a ratfor to c translator; I'm inquiring about it.
-------

Date:     Mon, 3 Oct 83 9:26:53 EDT
From: Ron Minnich <rminnich%udel-eecis1.udeecis%udel-eecis1@UDel-Relay>
Return-Path: <rminnich%Udel-Eecis1%Udel-Eecis1@UDel-Relay>
Subject:  GNU
Received: from udel-ee by udel-relay.ARPA ; 3 Oct 83 09:34:03 EDT (Mon)
To: rms@mit-mc
ReSent-date: Thu 13 Oct 83 06:57:19-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

   I guess this is an idea whose time has come... I was thinking of 
doing the same thing. As it is I am writing a book- a la Software Tools-
of tools that do not exist under Un*x. I took the book route because 
I want to distribute source, and that seems the most effective route. 
Additionally, I have to eat. 
   Anyway, I will try to contribute what time I can. My only reservation 
is in adding too much incompatibility to Unix. No question Unix 
a dog in many ways, but it would be a shame to see GNU die because
everyone decided to put in their favorite 'extension'. I've seen that 
happen a couple different times at a couple different companies.
Extensions, no matter how benign, imply incompatibility. Best keep 
them limited. 
   Here's hoping it comes off!
   Ron

Received: from UCBERNIE.ARPA by ucbvax.ARPA (4.12/4.7)
	id AA05583; Tue, 11 Oct 83 09:17:29 PDT
Date: 11 Oct 83 09:17:38 PDT (Tue)
From: jf%UCBERNIE@Berkeley (Jay Fenlason)
Message-Id: <8310111617.AA01718@UCBERNIE.ARPA>
Received: by UCBERNIE.ARPA (3.336/3.7)
	id AA01718; 11 Oct 83 09:17:38 PDT (Tue)
To: info-gnu@mc

Hello everyone.  I'm Jay Fenlason, a graduate from the infamous Lincoln-
Sudbury Regional High School, now an undergrad at UCB (Where else?).
I'm gonna write the logo interpreter and the rogue-style game for Gnu.
(One of them's easy).  If you have any comments/suggestions for either
of them (Which syntax you'd like your logo to use, for instance) mail
them to jf@ucbernie.

			J

Date: Tue, 11 Oct 83 05:35:16 PDT
From: efrem@LBL-CSAM (Efrem Lipkin)
Return-Path: <efrem@LBL-CSAM>
Message-Id: <8310111235.AA03989@lbl-csam.ARPA>
Received: by lbl-csam.ARPA (4.6/3.35)
	id AA03989; Tue, 11 Oct 83 05:35:16 PDT
To: RMS@MIT-MC.ARPA
Subject: GNU
ReSent-date: Wed 12 Oct 83 00:53:07-EDT
ReSent-from: RMS%MIT-OZ@MIT-ML.ARPA
ReSent-to: info-gnu@MIT-MC.ARPA

Dear Richard,

I fly off to Spain and Morocco in a couple of hours and will not be back
until the middle of November.  However, I wanted to voice my support before
leaving.  When I come back that support should become more tangable.

I am Efrem Lipkin, the originator of the Community Memory idea and one
of the founders of the Community Memory Project.  I am a designer of things
including languages, database systems, networks, governance methods, and an
occasional solid or celluloid object.

I recently left Community Memory to attempt working in a less binding and
bickering fashion.  I am working on database software which I plan on
eventually having in the public domain.  I am working with a few peoplew
scattered around the continent on another approach to establishing a public
communications  medium.  I am also developing tools which
may be relevent to GNU.  I must fly, but will be back in contact in 
November.  Then we must have a descussion of what free software actually
costs and who pays for it.
			
			Efrem

EFREM@LBL-CSAM.ARPA

lbl-csam!efrem  (off ubcvax if not via arpa)

1811 Ward Street
Berkeley, CA 94703
(415) 845-3170


From: rej@Cornell
Date: 4 Oct 1983 23:13-EDT
Subject: Gnu
Message-Id: <83/10/04 2313.390@Cornell>
Received: by GVAX.CORNELL (3.320/3.14)
	id AA23313; 4 Oct 83 23:43:53 EDT (Tue)
To: RMS@MIT-MC
ReSent-date: Fri 7 Oct 83 18:30:22-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

I read your article about GNU with great interest.  If you had started
this a couple of years ago I would have been glad to give some time, but
those days are gone for a while.  Since you are most well known for work
on non-Unix systems, I wonder how well you know some of the inside Unix
information.  For example, are you aware that Berkeley 4.2 has much
longer filenames than Bell Labs versions?  Do you not consider curses
and termcap or ncurses and terminfo to be terminal-independent display
support?  Are you aware of the large amount of public domain Unix
software (I only know the tip of the iceburg).  Please let me bore
you for a minute or two.  If any of the following facts are new to you
then please let me know.

Berkeley Unix 4.2 contains many interesting enhancements to Unix that
support networking, multi-process programming, and other features that
it appears you will need.  Bell Labs plans to extend their version of
Unix to include the features of Berkeley's.  Thus, if you want to
provide standard interprocess communication, follow the 4.2 standard.

Most of the public domain C compilers are crummy.  However, I have
heard good things about the DECUS C compiler.  It is for the 11 and
maybe the VAX.  It has been around for awhile, so it might be V6
compatible instead of V7, but I don't think so.  In any case, if you
are only interested in getting a compiler for a few instruction sets
(i.e. 68000, VAX, PDP-11, and the like) then it might do.  It looks to
me like you are more interested in LISP than in C, so I am suggesting
this as a way of avoiding the considerable time cost of writing a C
compiler.

The University of Toronto has created a Unix look-alike in Pascal.  I
don't know if it is public domain, but it is supposed to be extremely
portable.  You might be able to get a lot of utilities from then,
though your O.S. design goals are much more elaborate.

Please keep the net up to date on your work.  I am sure that we will
all be fascinated.

	Ralph Johnson

Date: Wed, 5 Oct 1983  19:04 EDT
Message-ID: <[MIT-OZ].DCB.TECH. 5-Oct-83 19:04:40>
From: DCB.TECH@MIT-OZ
To:   sys-people@MIT-CCC
Subject: Software Tools User Group query
Cc:   info-gnu@MIT-MC

Do any of you folks know anything about the Software Tools User group?
GNU (a group that wants to develop a public-domain operating system
that's compatible with Unix) wants to incorporate their stuff.  Is
there anyone accessible on the net who could give us permission to
snarf sources from somewhere else?  Is there a formal policy, outside
of "public domain"?
tnx in advance,
	rich$alz

Date: Tue 4 Oct 83 19:55:43-EDT
From: RMS@MIT-OZ
To: info-gnu@MIT-MC

Can anyone find out for me a COMPLETE list of what is
available from Software Tools?

Can anyone find out for me exactly what parts of the Berkeley
distribution are available for GNU to use?

These tasks are vital, since there is no way I can begin
telling people what work needs to be done until I know the answers.
-------

Date: Mon 3 Oct 83 19:56:04-EDT
From: PLEASANT@MIT-OZ
Subject: addition to mailing list
To: info-gnu@MIT-OZ

Please excuse this message if it reaches everyone on the mailing list
but I could not find a -REQUEST address.  Please add me to this list.
My preferred address is PLEASANT@RUTGERS.

-Mel
-------

Date: 2 Oct 83 22:56:40 PDT (Sun)
From: Howard Alt <alt@aids-unix>
Subject: mark@umcp-cs
Message-Id: <8310030556.AA19884@aids-unix.ARPA>
Received: by aids-unix.ARPA (3.326/3.14)
To: RMS@MIT-OZ, info-gnu@MIT-MC


yes, send it to mark.umcp-cs@udel-relay.  umcp-cs is a CSNet site.
			Howard.

Date: 30 Sep 83 23:04:25 EDT (Fri)
From: decvax!cg-d!clarke
Subject: GNU
Message-Id: <8310010304.AA05631@decvax.UUCP>
Received: by decvax.UUCP (3.326/3.7)
	id AA05631; 30 Sep 83 23:04:25 EDT (Fri)
To: decvax!genrad!mit-eddie!RMS@MIT-OZ
ReSent-date: Sun 2 Oct 83 23:46:22-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC


Assuming you are not kidding, I am interested.
I see some problems with individuals creating and testing
code under Unix.  Since your file system and terminal
interfaces will be different it will be necessary to
create libraries similar to Berkeley's directory package
so that coding and testing can be done on any Unix system.

All that I can contribute is man hours.  I am the project
leader for the Operating Systems section of the Tools Group
at Compugraphic Corporation.  I am interested in operating
systems and compilers.

I would certainly like to hear more.

Carlos Clarke
uucp decvax!cg-d!clarke
snail
	Compugraphic Corporation
	200 Ballardvale St. Dept. 643
	Wilmington, Mass. 01887



Date: Sun 2 Oct 83 23:46:04-EDT
From: RMS@MIT-OZ
To: info-gnu@MIT-MC

Does anyone know how to reply to the message from "mark@umcp-cs"?
I cannot find any way to do so.
-------

Date:     30 Sep 83 23:28:00 EDT  (Fri)
Original-From:     Mark Weiser <mark@umcp-cs>
Subject:  GNU
To: rms@mit-oz@mit-eddie
ReSent-date: Sun 2 Oct 83 23:44:43-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

Exciting!

We have extended the public domain Tiny-C compiler to be just 
about all of C, if that would be any help to you.

Keep me informed.



Date: Sun, 2 Oct 1983  11:00 EDT
Message-ID: <[MIT-OZ].DCB.TECH. 2-Oct-83 11:00:43>
From: DCB.TECH@MIT-OZ
To:   info-gnu@MIT-OZ

does anyone know if ccc is in the Software Tools User Goup?  If so,
maybe GNU could just join and save the $50 tape fee.
	-rich$alz

Date: Saturday, 1 October 1983, 03:12-EDT
From: Richard M. Stallman <RMS at MIT-OZ>
Subject: How to forestall Bell's claims if there are Unix sources where you work.
To: INFO-GNU at MIT-MC

I have it on good authority that people are distributing compatible code
and as long as an inspection of it shows that it is not copied from Bell
code they are having no problems.  If you write a replacement for a
reasonable size program, and you have not read Bell's version, it is
nearly certain that they will not look very much alike.

If you have looked at the Bell code at some time in the past,
think about some key aspects of how the program was organized
and pick a different way to do it.  This will make sure that all
the minor details come out different as well.

An alternate technique suitable for certain utility programs
is to write them in Lisp.  Use Franz Lisp.  They won't resemble
Bell's C programs very much.

There may be a few library subroutines that are so trivial that one
can hardly find two ways to write them.  I don't think it will matter
if there are resemblances in such subroutines, as long as the bulk
of our code is clearly different.

Date: Sat 1 Oct 83 02:16:00-EDT
From: RMS@MIT-OZ
Subject: Writing the subroutine library
To: info-gnu@MIT-MC

BARRYS%OZ@MIT-MC says he is interested in writing the replacements
for the standard subroutines such as PRINTF.
-------

Received: by ucbvax.ARPA (4.12/4.7)
	id AA12139; Fri, 30 Sep 83 12:39:12 PDT
Date: 28 Sep 83 15:37:16 EDT (Wed)
From: cbosgd!mark@Berkeley (Mark Horton)
Subject: Re: new UNIX implementation
Message-Id: <8309281937.AA01808@cbosgd.UUCP>
Received: by cbosgd.UUCP (3.327/3.7)
	id AA01808; 28 Sep 83 15:37:16 EDT (Wed)
To: RMS@MIT-MC.ARPA
References: <771@mit-eddie.UUCP>
ReSent-date: Sat 1 Oct 83 02:14:50-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

Great!  I applaud your effort and wish you the best.  I wish I had either money,
time, or hardware to donate, but about all I can manage is advice.

I realize that GNU is going to be significantly influenced by ITS.  Since ITS
has many good things, this is probably good, for the most part.  However, I
hope you have already taken quite a bit of time to become familiar with UNIX
(a good implementation, such as 4.2BSD) and hopefully will be able to look at
several flavors of UNIX to get a feel for the differences.  (At a minimum,
I think you should become familiar with 4.2BSD, V7, and System III or V.)

>From a legal point of view, please be careful ahead of time that what you do
is really public domain.  In particular, talk to a couple people like Mark
Williams to see what they did.  Basically, I think you are allowed to look
at UNIX all you want, but at some point you have to say "OK, now I'm starting
to develop GNU and have thrown away all source code."  Then you no longer have
access to any UNIX source code.  (This may be tricky, since if you continue
to be employed by MIT they can argue that you had access to MIT's copy of the
UNIX source code.  You need to be able to document that you in fact did not
make use of this.  An even harder problem is to be able to document that the
people who contributed code did not use any UNIX source code.)  I believe you
are allowed to have a copy of the V7 manual (and therefore a 4.2BSD manual).

One thing you should do is make sure you have a 4.2BSD tape and go through it
to determine what things on it are based on UNIX/32V and what things are not.
(I will be happy to answer questions about that if it will help.)  Everything
on that tape that does not have some piece of 32V in it is public domain.
Much of that will no doubt be helpful to you.  For example, the 4.2 filesystem
has long names and is an order of magnitude faster than the V7 filesystem.
Since the 4.2 filesystem was entirely written at UCB, it should be PD.

You said you intend GNU to be able to run UNIX programs.  I hope this means
that any (source) program that runs on UNIX will run on GNU (or at least 95%
of them).  This will be hard to do since there are so many flavors of UNIX
to choose from.  You'll also have the delemma of choosing between the best
version (4BSD) and the "standard" version (System V) for compatibility.  In
many cases you can probably be compatible with the best of both.  But in any
case, document from the start which version or versions you claim compatibility
with.

Spend a lot of effort on your C compiler.  Experience with UNIX ports is that
roughly half the work of the whole port goes into cc.  Of course, each different
piece of hardware needs a different compiler, so this will be a gigantic effort.
A complicating factor is that I know of no public domain C compiler for ANY
piece of hardware (except for the Tiny C that was posted to Usenet, which I
think is for some 8 bit machine).  Almost all of them are based on Johnson's
pcc, and are therefore covered by the UNIX license.  Perhaps you'll be able
to get some help from Robert Henry at Berkeley (rrh@Berkeley.ARPA) who has
been doing research on portable code generators.  I think the 4.2BSD C compiler
has his stuff for a back end.  You'll still have to do a public domain front
end, but the front end is the easy part (given a PD parser generator).  Don't
just adopt the C book as your definition of C - there are a few important
extensions that everyone has now: structure assignment, enums, void, being
able to have fields of different structures with the same name but different
offsets, and flexnames.  (flexnames will be in the next release of System V,
so they have become universal.)  There is talk of allowing a readonly parameter
type and a way to declare the types of parameters so the compiler can check them,
but so far it's just talk.

As for terminal independent screen handling, I won't get into that argument
with you here - you and I have different philosophies on the subject.  Just
be aware that all other UNIX variations do the terminal dependent stuff in
user code based on TERM in the environment - it's generally considered a bad
idea in UNIX for the kernel to know or care what kind of terminal you have,
because it's bad to keep a screen image in the kernel and it's hard to debug
the kernel when a new braindamaged terminal exists.  People have come to expect
that termcap or terminfo will be supported (with its 200 terminal types)
including terminals that do xon/xoff.  The termcap/termlib/4.1BSD curses code
is all public domain.  There is also a public domain version of terminfo and
Pavel Curtis (pavel@cornell.arpa) has a PD version of a smart terminfo curses.
(I have a copy of Pavel's code which I will be giving to Berkeley next week
for 4.3BSD.)  However, rather than get into the philosophical issues, I merely
urge that compatibility be the primary concern, and if you want to implement
curses in the kernel that you at least provide a compatible interface for
programs.

You mentioned doing Chaosnet and possibly UUCP.  My opinion of UUCP is that
the best fix for it is to take it out and shoot it.  However, there is a lot
of UUCP out there.  It will be very hard to implement a PD UUCP because the
protocol is not documented anywhere.  If you choose to do it, talk to Lauren
Weinstein - he knows it better than any other human.  But I think it would be
acceptable if you provided a real network that could replace UUCP and made it
PD.  If it is sent out to everybody perhaps UUCP can be stamped out.  I am not
very familiar with Chaosnet but I thought it wanted to run on Ethernet style
hardware.  The one good thing about UUCP is it works on dialup phone lines,
and a site can get on without even having a dialer if they just have a dialup
and somebody willing to poll them.  (That plus there are no political funnies
with getting permission to get on the net.)  There are an estimated 1500-2000
UUCP hosts in the world, and nobody has a list.  (There is a request for funding
for a UUCP registry and map service before Usenix right now.)  If you can
provide something that will implement TCP/IP over dialup phone lines (an
interesting problem given limits like not having a dialer, the dialer being
busy, the other phone being busy, and timeouts of 15 seconds vs the 1 minute
or more it can take to complete a phone call) the world will thank you profusely.

	Mark Horton
	Bell Labs, Columbus, Ohio
	mark@Berkeley.ARPA
	mark@cbosgd.UUCP
	(614) 860-4276

Date: 29 Sep 1983 11:56:10-EST
From: EEvax.kraines@purdue
To: csvax.rms@mit-mc.arpa
Subject: GNU sounds great!!
ReSent-date: Sat 1 Oct 83 02:14:40-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

Richard,

    I think it is a great idea to write gnu.  I have a suggestion
that could speed up your task greatly.  The Software Tools Users
Group (STUG) has a large number of UNIX-like tools written in
ratfor that are public domain.  Ratfor has a C-like syntax, so
C programs can easily be rewritten in ratfor.  For your task
you could rewrite ratfor programs in C.  You can join STUG for
about $15 and get a distribution tape for about $50.  They
have a standard tape, and a few versions for different operating
systems.  Some even include a shell.  You can contact Bob 
Upshaw at bobup@lbl-csam  (Lawrence Berkeley Labs) or use
the STUG hotline 415-486-4680.  

   For those of us who use UNIX at a university, are there any
legal complications to us writing programs in C and submitting
them to you?

sincerely,

--larry kraines


                        eevax.kraines@purdue
			decvax!pur-ee!kraines
			ucbvax!pur-ee!kraines
			ihnss!pur-ee!kraines
			inuxc!pur-ee!kraines
			pur-ee!kraines@berkeley

Date:  30 September 1983 15:19 hfh
From:  Bakin.AWEST at MIT-MULTICS
Subject:  New UNIX
To:  RMS at MIT-MC
Acknowledge-To:  Bakin.AWEST at MIT-MULTICS
ReSent-date: Sat 1 Oct 83 02:12:47-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

Mr. Stallman:  You are a true visionary!

[I don't know you personally, but let me offer the following:  When I
started reading your message on the hi-multics forum at 300 baud, I
thought "this person has delusions of grandeur .. it'll never get done"
Very sneaky of you to put your name in the middle of the message!  I
believe you can organize and complete this effort.]

So, please add my name to your mailing list and accept my offer of help.
I would like to be one of the persons rewriting Unix utilities.
Eventually I would like to do more, but currently I am working in France
under conditions that are not suited for spending my free time
programming for pleasure.  (That is, I have no computer or terminal at
home.)  Another thing you may like to know is that although I have over
10 years experience in compiler development and other system development
I have never actually used Unix!  (I have used Multics, though.)  So, I
think I will need to start off easy.

We have an Altos 68000 here (I work for Alsys Microsoftware developing
Ada compilers for micros) that is running Unix System III.  So I have
access to documents and a working Unix system.

Please, let's discuss what I can do to help you and GNU.  Some of my
experience may be better suited to certain utilities than others, though
I am not that picky.  And, good luck!

-- David S. Bakin

Date: Fri, 30 Sep 83 13:33:42 PDT
From: kpno!brown@LBL-CSAM
Return-Path: <kpno!brown@LBL-CSAM>
Message-Id: <8309302033.AA04969@LBL-CSAM.ARPA>
Received: by LBL-CSAM.ARPA (3.347/3.35)
	id AA04969; Fri, 30 Sep 83 13:33:42 PDT
To: lbl-csam!RMS@MIT-MC.ARPA
Subject: Re: new UNIX implementation
References: <771@mit-eddie.UUCP>
ReSent-date: Sat 1 Oct 83 02:12:18-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

Count me in.  I'll be happy to try and hack some utilities together.

	regards,
	Mike Brown	Kitt Peak National Observatory
			Tucson, Arizona			(602) 325-9249	

	{arizona,decvax,hao,ihnp4,lbl-csam,
	 sdcarl,sdcsvax,seismo,unc,utastronomy,ut-sally}	!kpno!brown


Date: 30 Sep 1983 1412-PDT (Friday)
From: Howard Alt <alt@Aids-Unix>
Message-Id: <9963.81.433804335@Aids-Unix>
To: RMS@MC
Fcc: outbox
Subject: UNIX Work.
ReSent-date: Sat 1 Oct 83 02:12:09-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC


Hi.  My name is Howard Alt.  You met me in San Francisco with Geoff
Goodfellow, and we went out to dinner (I think you were here to show
Berkeley some new LMI software).  Anyway, I am a UNIX hacker, and
I am willing to write software for you for free.  I have a job
working for a company here in mountain view CA, and am quite happy,
however I agree with a few of your points, and I would like
to help your effort in any way I can.
			Howard.

Date: 30 Sep 1983 18:07:31-EDT
From: mp at mit-vax
To: rms@mit-oz
Subject: another one (found in dead letter bin because of typo)
ReSent-date: Sat 1 Oct 83 02:11:37-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

Date: 28 Sep 1983 18:33:46-EDT
From: eagle!mhuxi!mhuxj!mhuxl!mhuxm!pyuxi!pyuxss!aaw at mit-vax
To: pyuxi!mhuxm!mhuxl!mhuxj!mhuxi!eagle!mit-vax!RMS@mit-oz
Subject: Re: new UNIX implementation
References: <771@mit-eddie.UUCP>

I might be interested in helping the programming part of your gnu,
(with the proviso that currently I do not have a development machine
of my own...and don't want to develop stuff without authorization on
my employers).
who am I: I've worked on a lot of database projects (special purpose
databases, design/develop using vendor dbms, etc. on a lot of
different machines/os/languages and developed several db query
langauges. Right now I am in charge of testing a medium sized IBM/IMS
database application (much less code, much more data than UNIX).
I am not a UNIX guru/internals anything i.e. I look at the code write
my own utilities but no touchy the kernal.
interests: dbms, languages, development environments (not OS's).
	also interested in public domain software.
		let me know if I can help
			Aaron
			pyuxss!aaw
			Bell Labs Piscataway NJ Rm.1J-236
			(201)981-6751




Date:     Thu, 29 Sep 83 20:07:41 CDT
From: Stan.Hanks <stan.rice@Rand-Relay>
Return-Path: <stan%rice.Rice@Rand-Relay>
Subject:  Re: new UNIX implementation
To: RMS@MIT-MC
Message-Id:  <1983.09.29.20.07.41.170.09778@Rice-vms.rice>
In-Reply-To: RMS.MIT-OZ's message of 27 Sep 83 13:35:59-PDT (Tue)
Via:  Rice; 30 Sep 83 15:27-PDT
ReSent-date: Sat 1 Oct 83 02:11:25-EDT
ReSent-from: RMS@MIT-OZ
ReSent-to: info-gnu@MIT-MC

Richard,

Funny how these things work. There is a small group of us here at Rice
University that have much the same sentiments. We have worked on
designing a new Unix-compatible system that has our favorite things in
it, and would probably like to get in on GNU. I know that I would at
the very least.

So, count us in, and let me know (a) exactly what is going on, (b) what
version of Unix this is to be compatible with (I personally like V7
with some of the UCB extentions and TCP/IP), and (c) what we can do.

Also, could you tell me who I have to kill to get a copy of your
original EMACS paper?? No one seems to know. Thanks much.

				Stan Hanks
				Department of Computer Science
				Rice University
				Houston TX
				
				stan.rice@rand-relay   (arpanet)
				stan@rice              (csnet)
				...!lbl-csam!rice!stan (uucp)

p.s. we are soon to be a virtual ARPAnet machine via the BBN-CIC
     CSNet X.25/ARPAnet gateway, so this will be somewhat easier.
     --sph


Date: Wednesday, 28 September 1983, 02:20-PDT
From: Bill Palmer <whp4 at SRI-KL>
Subject: new member of the gang
To: info-gnu at mit-mc


I read RMS' message to unix-wizards today and immediately fell in love
with the idea of a winning operating system available to anyone and
everyone for the asking.  Consequently, I want to volunteer my skills as
a programmer to the effort to build this sucker.  Tops20 and lispms are
my home environment but I'm willing to learn new worlds to help make
this great idea fly.  It really bothers me to pay DEC large sums of
money for the right to have the sources to fix their broken code or to
deal with all the Un*x people who won't even admit you exist if you
can't send them a certified copy of your Un*x source license.  Put me on
the list, I guess, and I'll help as best I can.

						Bill

Date: 23 Sep 83 01:24:26 EDT
From: Charles Hedrick <HEDRICK@RUTGERS.ARPA>
Subject: my offer of assistance
To: rms%MIT-OZ@MIT-ML.ARPA
cc: info-gnu%MIT-MC@MIT-ML.ARPA

Let me make it clear that at the moment my interest is personal. That
means that this is going to have to be on the basis of my "spare time".
At this stage in the game I am not prepared to  commit Rutgers to
anything on an institutional level, which means that I can't promise to
assign staff to it.  I should say that I have done significant software
development in my spare time, towit all of my DEC-20 Pascal work, and
the original version of Elisp. So I think I can get something done for
you.  But I don't want to give anybody the impression that I am going to
redirect the whole Rutgers software development organization in this
direction. (And at the moment I am deep in the throes of trying to
figure out in what direction our computing should be going next.  My
spare time at the moment is negative.  This has to change, however, as I
can't live for very long without some time out for hacking.)
-------


Date: 23 Sep 1983 0058-EDT
From: RMS@MIT-OZ
Subject: Latest Gnews.
To: info-gnu@MIT-MC

Hedrick@Rutgers is interested, and is offering to contribute a Pascal
compiler and a Common Lisp system.

Martin Minow has mailed me a tape of his stuff.

I'm looking for possible directors and officers for a foundation
to receive donations to GNU, to make them tax-deductable.
If you have any ideas, please tell me.  They may need to be people
in the Boston area.  Does anyone have experience with setting up
a charitable organization?
-------

Date: Sunday, 18 September 1983, 18:29-EDT
From: Tom Cloney <EB.TFC@MIT-OZ>
To: info-gnu@mit-mc


Is this the beginning of gnu-wave?


Date: Sunday, 18 September 1983, 18:27-EDT
From: Tom Cloney <EB.TFC@MIT-OZ>
To: info-gnu@mit-mc


Date: 2 Sep 1983 03:47:13-EDT
From: allegra!phr at mit-vax
To: mit-vax!rms@mit-oz
Subject: Berkeley, yacc, etc.
Cc: mit-vax!info-gnu@mit-mc

Well, I'm a student at Berkeley now, so until I find a place
to live I'm staying with a friend in San Francisco and missing
the Worldcon.  I spoke with Prof. Fateman today about an independent
CS project to write yacc; he seems willing but wants me to
write it in Lisp, which I guess is ok.  I should get started
fairly soon.


Return-path: <COMSAT@MIT-MC>
Date: 1 September 1983 01:02 EDT
From: Communications Satellite <COMSAT @ MIT-MC>
Subject: Msg of Thursday, 1 September 1983 00:59 EDT
To: RMS @ MIT-OZ
Remailed-date:  1 Sep 1983 0125-EDT
Remailed-from: RMS@MIT-OZ
Remailed-to: info-gnu@MIT-MC

============ A copy of your message is being returned, because: ============
"GNU" at MIT-MC is an unknown recipient.
	Will try sending to the file "GUEST1;GNU MAIL".
============ Failed message follows: ============
Date: Thursday, September 1, 1983 12:53AM-EDT
From: Richard M. Stallman <RMS@MIT-OZ>
To: gnu at MIT-MC

A visitor from France, WORLD.PMS@MIT-OZ, was here and reports
that at his University they have written much free unix software.
He is eager to donate it to us.  I'm not sure exactly what it includes;
our attempts to read his tape were a failure due to a crashing vax.
He is going to mail me a tape.

He also spoketo Paul Rubin and gave him a reference to a paper
which is said to contain an algorithm with which a YACC can easily
be written.  Paul is interested in writing one.

Date: 17 Aug 1983 18:26:27-EDT
From: allegra!phr at mit-vax
To: mit-vax!info-gnu@mit-mc
Subject: Software Tools from Martin Minow

Here's the latest piece of mail.  I've asked for a copy of his tape.

	From decvax!minow Wed Aug 17 01:21:41 1983
	Date: 16 Aug 83 21:27:33 EDT (Tue)
	From: decvax!minow (Martin Minow)
	Subject: Re:  C Compiler
	Message-Id: <8308170127.AA04656@decvax.UUCP>
	Received: by decvax.UUCP (3.326/3.7)
		id AA04656; 16 Aug 83 21:27:33 EDT (Tue)
	To: allegra!phr
	
	Most of the "core" Unix tools are present, including grep, diff, sortc,
	kwik, a text archiver.  There is also a lex, but no yacc.  Also a
	whole bunch of random stuff -- cross assemblers for several micros,
	some games, and lots more.
	
	The second release was just sent to Decus last month.
	
	I'd be happy to send you a tape of the tools, but don't have any
	facility to create tar format, so you'll have to do battle with
	an editor to extract the files.
	
	Martin.
	


Date: 16 Aug 1983 15:24:14-EDT
From: allegra!phr at mit-vax
To: mit-vax!rms@mit-oz
Subject: Martin Minow and the DECUS C compiler
Cc: mit-vax!info-gnu@mit-mc

Here's some mail I've gotten from Martin Minow, author of DECUS C.
I might get interested in translating his compiler to C, along with the CTL
preprocessor, or something like that; also I've sent him mail asking
for more details about the other tools on the DECUS tape.  Martin has
asked to be added to the mailing list - Richard, could you take care of
that?  His address is decvax!minow@mit-vax.  Thanks.

	paul


>From decvax!minow Fri Jul  8 15:46:26 1983
Date: 7 Jul 83 20:25:35 EDT (Thu)
Full-Name: Martin Minow
Subject: Re:  C compiler
Message-Id: <8307080025.AA12479@decvax.uucp>
Received: by decvax.uucp (3.326/3.14)
	id AA12479; 7 Jul 83 20:25:35 EDT (Thu)
To: allegra!phr, decvax!minow

Decus C is a totally public-domain C compiler.  You may do anything
with it that you want.  (Wait a bit before you order it, there's a
later release on its way).

The idea of porting it will be an interesting project as the compiler's
100% written in PDP-11 Macro.  It is possible to split out the code
generator part (which reads a file produced by the parser) to write
your own 16000 code generator.  But it will be a fair amount of work.
(Someone did just that to create a 68000 compiler for a compiler course.)

The distribution may be interesting even if you don't use the compiler as
there are about 20 utility programs (diff, sort, etc.) that might be
helpful.

Have fun, but don't say I didn't warn you.

Martin.

Date: 14 Aug 83 11:55:33 EDT (Sun)
From: decvax!minow (Martin Minow)
Subject: Re:  C Compiler
To: allegra!phr, decvax!minow

Sorry about the delay -- I was on vacation for 5 weeks.  Decus C
supports most of the language, lacking bitfields, structure assignments,
enum's, "block structure", assigned local declarations, and probably
a few other minor things.

The utilities all run reasonably well on unmapped '11's (under DEC RSTS,
RT11, and RSX operating systems); but a few require overlays.

Retargeting the compiler isn't trivial, but isn't impossible.  It has
two passes (+ the preprocessor) and the intermediate file is written
as a readable ascii file.  The final pass thus contains all target
code generation, along with register assignment and expression optimization.
The compiler, while written in DEC macro assembler, is very well documented.

I'll reread your message and see if I left anything out.  Oh yes, the
built-in preprocessor doesn't support macros with arguments or
the "#if defined(foo) && ..." construction.

Hope this helps.

Martin Minow

	[from another message]
Oh yes, the generated code is as good as any pdp-11 compiler.  There
are a few things that could be improved -- it will generate branches
to branches, for example, but expression evaluation and local optimizations
are done very well.

Good luck with gnu.  I keep wanting to write a public domain Unix too.
(Gonna call it PUBIX, which is as vulgar a pun as I can get away with:
since Unix is a casterated Multix, PUBIX replaces a missing feature of
Unix.)

Martin.


Date: 12 Aug 1983 14:26:01-EDT
From: allegra!phr at mit-vax
To: mit-vax!mp@mit-vax
Subject: Re: related work at UCSD
Cc: mit-vax!info-gnu@mit-mc

By 'Public Domain' Donn means available to Unix(tm) licensees.
I sent him some mail a couple days ago asking if he were interested
in a \real/ public domain system; haven't gotten any reply yet.

	paul


Date: 11 Aug 1983 12:32:42-EDT
From: mp at mit-vax
To: info-gnu@mit-oz
Subject: related work at UCSD

>From eagle!harpo!decvax!linus!philabs!sdcsvax!sdchema!donn Mon Aug 15 02:57:04 1983
Subject: A Proposal for a 'Public Domain' 4.2 BSD Port to the 68K
Newsgroups: net.unix-wizards,net.works
I inquired earlier over the net about the status of implementations of
4.2 Berkeley Unix on the 68K.  The substance of the replies I received
was that:

  -	There is no 'public domain' (needs only Unix license) 68K
	implementation either in existence or being planned.

  -	The only commercial implementation likely to appear in the near
	future will be from Sun Microsystems, for the Sun architecture
	machines.  Sun apparently does not sell source unbundled from
	hardware; I am unsure whether they will sell source at all, in
	fact.  I have not personally contacted Sun about this.

  -	Some companies may be working on other implementations but they
	are not very close to release.  No one seems to be working on
	an implementation for new boards like the PMD 68010-based
	system with dual-ported on-board memory (so that DMA devices
	can go directly to CPU memory and not incur Multibus
	overhead).  This circumstance may not last for long.

Some people replied that they would be interested in seeing a 'public
domain' version of 4.2 on the 68K, especially for the new architectures
such as the dual-ported memory boards and Q-bus systems, and perhaps
could offer their services in helping to develop such a system.

I had grandiose thoughts of doing a port with just the resources here
at UCSD earlier, but decided not to get involved unless new funding was
approved and we got more staff to handle the effort.  However if there
are enough interested systems programmers out there who would like to
engage in a 'public domain' 4.2 port, maybe a joint effort with
different people working in different parts of the world could do the
job regardless of the funding situation at individual sites.  Things
like this never work exactly the way you expect them to, but there are
undoubtedly some very competent individuals out there who can flourish
without the handholding that a completely local development effort
provides.

I want to test the waters now and see just how many people would be
interested in contributing to a 'public domain' 68K 4.2 BSD port.  UCSD
Chemistry would be willing to serve as a coordinating site for such a
venture.  It would be a good test of the software development network
that UCSD Chemistry has suggested setting up as part of its recent NIH
grant proposal, as a matter of fact.  As a starting point, we have
talked to individuals at Pacific Microsystems, who are located here in
San Diego and manufacture the 68010-based, dual-ported memory board
which I mentioned above, and they seem receptive to the notion of such
a port (in other words, they are not planning on making any software
effort of their own).  We may be able to get discounts on hardware from
them if we can come to them with a concrete proposal; the word is that
they would be happy with a 'public domain' port rather than a
commercial port of their own, although we have not (repeat not) made
any deals with them yet.

If this sounds interesting to you, contact me through one of the
following addresses.  If enough people are interested, I will try to
get an organization formed and post a note indicating what people's
feelings are about how we should proceed.

Donn Seeley  UCSD Chemistry Dept. RRCF  ucbvax!sdcsvax!sdchema!donn
             (619) 452-4016             sdamos!donn@nprdc

USnail:	Donn Seeley
	UC San Diego Chemistry Dept.
	NIH Research Resource Computing Facility, B-014
	La Jolla, CA 92037


Date: Sunday, 7 August 1983, 16:35-EDT
From: Tom Cloney <eb.tfc@MIT-OZ>
To: info-gnu@MIT-MC

I am offering my services to the GNU group following my return from London in September.

I have put together an S-100 machine currently running an 8086/87 CPU with 128k static
RAM and a 40x85 char 480x512 pixel intelligent graphics interface. I will be adding
a 16032 CPU board and hopefully another 128k of RAM as soon as the board is marketed
which should be Sept.-Oct.. At present the system has 5M storage on four 8" floppies.
I am casting about for a cheap hard disk.

The system might make a good model for an inexpensive GNU development system. At present
I am working almost exclusively in FORTH and assembly language on the system and have
created a very flexible programming environment. FORTH has many similarities to LISP,
is MUCH easier to implement, and executes faster. In its basic form it lacks some of
LISP's more advanced features. 

I live down on the Cape and bounce back and forth (jeez!) between Cambridge and there
frequently. I have created a pleasant place for programming and I would be interested
in sharing it with others contributing to this project.

I am not the most experienced programmer in the world, but I'm learning and I might
be of some use to the group. I don't cost anything.

In addition to LISP and FORTH, I have a bit of experience with BASIC, FORTRAN, and PASCAL.
I have done quite a bit of 8086/87 assembly language programming and a little on the
PDP-11.

							-- Tom Cloney --

Date: 2 Aug 1983 19:50:27-EDT
From: allegra!ima!stevel at mit-vax
Subject: Re: Test
To: allegra!mit-vax!info-gnu@mit-mc

Yes I got the gnu mailing. Please acknowledge this so I know I
can mail into the list.

Steve Ludlum, INTERACTIVE, PO Box 349, Cambridge MA 02238; 617-247-1155
decvax!yale-co!ima!stevel, {ihnp4|ucbvax}!cbosgd!ima!stevel,
decwrl!amd70!ima!stevel, {uscvax|ucla-vax|vortex}!ism780!stevel


Date: 30 July 1983 01:59 EDT
From: Richard M. Stallman <RMS @ MIT-MC>
To: INFO-GNU @ MIT-MC

The name of the mailing list has been changed
because there is a user named GNU!
So it is now INFO-GNU@MIT-MC.

Date: 29 Jul 1983 1625-EDT
From: RMS@MIT-OZ
Subject: Test
To: gnu@MIT-MC

Does everyone get this now?
-------

